JSON Formatter
Pretty-print, validate and minify JSON with precise error positions.
Developer & Security
Encode and decode text or files, with a URL-safe variant.
It solves one specific problem: moving binary data through a text-only channel without corruption.
Email is the original case. SMTP was defined for 7-bit ASCII, so an attached image had to be represented as printable characters — which is what MIME and Base64 do, and why every email attachment you have ever sent was Base64-encoded in transit.
The modern cases are the same shape. A JSON string field cannot hold arbitrary bytes, so a binary blob in an API payload is Base64. A CSS file cannot reference a file that does not exist, so a small inline icon becomes a data: URI. A JWT is three Base64url segments joined by dots.
What it is emphatically not is encryption. Base64 is a reversible encoding with no key. Anyone can decode it instantly. Encoding a password in Base64 provides no security whatsoever — it only makes the password non-obvious to someone glancing at a log.
Standard Base64 uses + and / as its 63rd and 64th characters, and = for padding. All three are reserved characters in URLs.
A + in a query string is decoded as a space by most servers, which silently corrupts the data. A / in a path creates a segment boundary. An = separates a parameter from its value.
RFC 4648 defines a URL-safe alphabet that substitutes - for + and _ for /, and usually omits the padding entirely. This is what JWTs use, and what you should use for any Base64 that appears in a URL, a filename, or a cookie value.
| Character | Standard | URL-safe |
|---|---|---|
| Index 62 | + | - |
| Index 63 | / | _ |
| Padding | = (required) | omitted |
| Safe in a URL | No | Yes |
| Safe in a filename | No | Yes |
Because it represents 3 bytes of input using 4 output characters, a fixed 4:3 ratio, which is a 33.3% expansion before padding.
That has a real cost when inlining images as data URIs. A 12 KB PNG becomes a 16 KB string. Inline it in CSS and every visitor downloads those extra bytes, and they cannot be cached separately from the stylesheet.
The rule of thumb: inline assets under about 4 KB, where eliminating an HTTP round trip outweighs the 33% penalty. Above that, a separate cacheable file wins — particularly over HTTP/2 and HTTP/3, where the cost of an additional request is much lower than it was when data-URI inlining became popular.
Correctly, which is worth stating because the naive approach fails.
JavaScript’s built-in btoa() throws on any character above U+00FF. Passing it "café" or an emoji produces an InvalidCharacterError, and a lot of code works around this incorrectly by mangling the string first.
The right approach is to encode the string to UTF-8 bytes first with TextEncoder, then Base64 those bytes. This tool does that, so Chinese text, Arabic, emoji and combining characters all round-trip exactly. Decoding reverses it through TextDecoder.
No. It is an encoding with no key, reversible by anyone in a second. It provides zero confidentiality.
That is padding. Base64 works in 3-byte blocks; when the input length is not a multiple of 3, one or two = characters pad the final block. URL-safe Base64 usually omits it.
Yes. Drop the image and you get a complete data URI you can paste into CSS or an img src. Keep it under about 4 KB or the size penalty outweighs the saved request.
Base64url swaps + and / for - and _ and drops the padding, so the result is safe in URLs, filenames and cookies. JWTs use it.
Usually the string was URL-safe Base64 decoded with the standard alphabet, or it was truncated. Check for - and _ characters and switch modes.
Device memory only. Files of tens of megabytes encode fine, though the resulting string is a third larger again.
No. Encoding uses TextEncoder and the native btoa in this page.