What is Base64?
Base64 is an encoding scheme that converts binary data into ASCII text using 64 characters (A–Z, a–z, 0–9, + and /). It's commonly used to embed images in HTML/CSS, transmit binary in JSON or HTTP headers, and store binary in text-based formats.
URL-safe Base64
Standard Base64 uses +, / and = — all of which have special meaning in URLs. The URL-safe variant replaces them with - and _ and drops the padding, making it safe to include in query strings, JWT tokens and similar.
Privacy
Encoding and decoding happen entirely in your browser. Your data is never sent to any server.
Base64 in practice
Base64 is used wherever binary data must travel through a channel that only accepts text. The most frequent cases:
- Image as a data URI —
<img src="data:image/png;base64,iVBORw0K…"> embeds a small image directly in the HTML or CSS, with no separate file or network request. Useful for icons or emails.
- HTTP Basic auth header —
Authorization: Basic dXNlcjpwYXNz is simply user:pass encoded in Base64. Use it only over HTTPS: it is not encrypted.
- Inspecting a JWT — paste a token segment (between the dots) into the decoder to read the header or payload in clear text.
- PEM certificates and keys — the block between
-----BEGIN----- and -----END----- is Base64. Decode it to examine the DER structure.
Base64 is not encryption
This is the most widespread security mistake. Base64 is fully reversible by anyone, with no key — it's just a change of alphabet, not protection. Never "encode" a secret in Base64 thinking you've hidden it: to protect data you need real encryption (AES, for example), and Base64 only serves, where relevant, to transport the encrypted result.
Frequently asked questions
Why is my Base64 output 33% larger than the input?
Base64 groups bytes in sets of 3 and represents each group with 4 ASCII characters. Three bytes (24 bits) become 4 characters (32 bits), an overhead of 4/3 ≈ 1.333. A 100 KB image encoded as Base64 will be roughly 136 KB. This overhead is unavoidable: it's the cost of representing arbitrary binary data using a printable 64-symbol alphabet.
Base64 vs hexadecimal: when should I use each one?
Hex represents every byte as 2 characters (100% overhead); Base64 averages 1.33 characters per byte (33% overhead), so Base64 is more compact. Hex is easier to read when debugging short values like SHA-256 hashes or memory addresses, since each nibble maps directly to a digit. For transporting large binary payloads — images, certificates, cryptographic keys — Base64 is the better choice. For displaying a hash or a signature, hex wins on readability.
Why does my JWT have dots (.) between the Base64 segments?
A JWT (JSON Web Token) is made of three independently Base64url-encoded parts — header, payload, and signature — joined by dots. Each part uses Base64url (- instead of +, _ instead of /, no padding =). The dots are fixed delimiters defined in RFC 7519; they are a JWT formatting convention, not something special about Base64 itself.
My Base64 string contains spaces or line breaks — is that normal?
Yes, in MIME contexts such as email attachments and PEM certificates. RFC 2045 requires a line break every 76 characters for compatibility with older mail systems. A .pem certificate starts with -----BEGIN CERTIFICATE----- and contains Base64 wrapped at 64 columns. If you're decoding Base64 from an email or a certificate, strip whitespace and newlines before decoding, or use a library that handles this automatically.
Standard Base64 vs URL-safe Base64: how do I know which one to use?
Simple rule: if your Base64 string will travel inside a URL (query parameter, path segment, cookie) or a JWT/JSON context, use Base64url (RFC 4648 §5) with - instead of + and _ instead of /. For email MIME attachments, PEM certificates, or any textual context outside of URLs, use standard Base64. The two variants are identical except for those two characters and the optional padding.
