What Base64 is for — and what it is definitely not for
Base64 is a binary-to-text encoding that represents every 3 bytes of data as 4 printable ASCII characters, so binary content can travel safely through channels that only handle text.
Base64 exists because email headers, URLs, JSON string values and HTTP headers were designed for text. Anything with a null byte, a newline, or a character outside the safe ASCII range has to be re-expressed before it can pass through them intact. Base64 is the standard way to do that.
It is also the single most misunderstood tool in this category. Encoding is not encryption, an encoded string is not obfuscated in any meaningful sense, and a decode failure is almost always a padding or alphabet mismatch rather than corrupt data. The sections below cover the mechanics, the two common alphabets, and how to diagnose a failed decode.
The mechanics, in numbers
- Ratio
- Every 3 bytes become 4 characters, so encoded output is about 33% larger than the input. A 1 MB image becomes roughly 1.37 MB of text.
- Alphabet
- Standard Base64 (RFC 4648) uses A–Z, a–z, 0–9, plus + and /, with = as padding. That is 64 symbols, each carrying exactly 6 bits.
- Padding
- Output length is always a multiple of 4. One = means the final group held 2 bytes; two = means it held 1. Strict decoders reject a string whose length is not a multiple of 4.
- Unicode handling
- Text is converted to UTF-8 bytes before encoding, so accented characters, emoji and non-Latin scripts round-trip correctly rather than throwing a range error.
- Where it runs
- Encoding and decoding happen in your browser. Nothing is uploaded — relevant when you are inspecting a token you should not be pasting into a random website.
- Security value
- None. Base64 is reversible by design and by anyone. It provides no confidentiality, no integrity and no authentication.
Three encodings you can verify by hand
Example 1: The padding rule made visible
M
Ma
ManTQ==
TWE=
TWFuOne byte produces two padding characters, two bytes produce one, three produce none. If you can read the padding you can infer the input length modulo 3 — one reason Base64 is not obfuscation.
Example 2: Inspecting a JWT payload
eyJzdWIiOiIxMjM0IiwibmFtZSI6IkFkYSJ9{"sub":"1234","name":"Ada"}A JWT is three Base64url segments separated by dots. The payload is readable by anyone holding the token — never put secrets in a JWT claim. Paste the decoded result into the JSON formatter to inspect nested claims.
Example 3: Encoding Basic auth credentials
demo:s3cretAuthorization: Basic ZGVtbzpzM2NyZXQ=HTTP Basic auth is Base64 of user:password — trivially reversible. It is only acceptable over HTTPS, and even then a bearer token or API key is the better choice. Generate a strong secret with the password generator rather than reusing one.
Why a decode fails, in order of likelihood
Direct answer: if a decode throws, check the alphabet first, the padding second, and copy-paste damage third.
The string uses the URL-safe alphabet
Base64url (RFC 4648 §5) replaces + with - and / with _, and usually drops the = padding. It appears in JWTs, OAuth state parameters and signed URLs. To decode one here, swap - back to + and _ back to /, then add = until the length is a multiple of 4.
Line breaks from an email or certificate
MIME Base64 wraps at 76 characters, and PEM files wrap at 64. Those newlines are not part of the data. Strip them — and remove the -----BEGIN CERTIFICATE----- header and footer lines too.
The string was truncated
A length that is not a multiple of 4 usually means the value was cut by a log line limit, a database column, or a spreadsheet cell. Fix it at the source; padding it out will decode to the wrong bytes.
It decodes to binary, not text
Encoded images, PDFs and compressed archives are not readable text, so the output will look like noise. That is not a failure — it means you need a binary tool, not a text decoder.
Treating Base64 as a security control
Encoding a config value, a coupon code or an internal ID does not protect it. If it must stay secret, encrypt it and keep the key out of the client. If it must be tamper-evident, sign it.
When Base64 is right, and when it costs you
| Situation | Verdict | Reasoning |
|---|---|---|
| Small icon inlined in CSS as a data URI | Reasonable | Removes one HTTP request. The 33% size penalty is small on a 2 KB icon and it cannot be cached separately. |
| Large image inlined in HTML | Avoid | The page grows by a third, blocks rendering, and cannot be cached or lazy-loaded. Serve the file and compress it instead. |
| Binary attachment inside a JSON API | Common and acceptable | JSON has no binary type. Prefer multipart upload or a presigned URL for anything above a few hundred kilobytes. |
| Hiding a value from users | Never | Every browser has a decoder built in. Use real cryptography. |
| Storing credentials in a config file | Never | Base64 in a repository is a plaintext secret with extra steps. Use a secrets manager or environment variables. |
How this page is maintained
The size ratio, alphabet, padding rules and UTF-8 handling described here match RFC 4648 and the encoding path this tool uses. The worked examples were encoded and decoded with this tool before publication.
Written and reviewed by the ToolsRacks editorial team. Last reviewed: .