How Base64 encoding works
Base64 encodes every 3 bytes of input into 4 printable ASCII characters by splitting the 24 bits into four 6-bit groups. Each 6-bit value maps to one of 64 characters (A–Z, a–z, 0–9, +, /). Here is the full encoding of the word Man:
| M | a | n |
|---|
| ASCII code | 77 | 97 | 110 |
| Bits (8-bit) | 01001101 | 01100001 | 01101110 |
| 6-bit groups | 010011 · 010110 · 000101 · 101110 |
| Decimal | 19 · 22 · 5 · 46 |
| Base64 char | T · W · F · u → TWFu |
Three input bytes produce exactly four output characters — a 4:3 size ratio. When the input is not a multiple of 3 bytes, = padding is appended to bring the output to a multiple of 4 characters.
When to use Base64 encoding
Base64 is the standard solution whenever binary data needs to move through a text-only channel. These are the five situations we see it used most often:
CSS data URIsbackground-image: url("data:image/png;base64,iVBOR...")
Embed small images or fonts directly into CSS to eliminate extra HTTP requests. Browsers treat the Base64 string as the file.
HTTP Basic AuthAuthorization: Basic dXNlcjpwYXNz
The "username:password" string is Base64-encoded and sent in the Authorization header. It is not encryption — just encoding.
MIME email attachmentsContent-Transfer-Encoding: base64
Email was designed for 7-bit ASCII text. Base64 lets binary files (PDFs, images) survive transport through mail servers that strip high-bit bytes.
Binary in JSON / XML{ "avatar": "iVBORw0KGgo..." }
JSON has no binary type. Base64 is the standard way to embed images, certificates, or any binary payload inside a JSON or XML field.
JWT payloadeyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.
JWT tokens are three Base64URL-encoded segments (header, payload, signature) joined by dots. The payload is readable by anyone — it's encoded, not encrypted.
Standard vs URL-safe Base64
There are two variants defined in RFC 4648. The only difference is how they handle the 62nd and 63rd characters, which affect URL compatibility:
| Variant | Characters 62–63 | Padding | Use when |
|---|
| Standard (RFC 4648) | A–Z, a–z, 0–9, +, / | Yes (= characters) | Email, data URIs, most APIs |
| URL-safe (Base64URL) | A–Z, a–z, 0–9, -, _ | No (stripped) | JWT tokens, URL parameters, filenames |
Common encoding mistakes
These are the encoding problems we see most often. Each shows the problematic input, the correct approach, and why it happens.
Encoding an already-encoded string
A common mistake when chaining operations. If your input looks like Base64 (A–Z, a–z, 0–9, +, /) with = padding, decode it first before encoding again. Double-encoding produces "U0dWc2JHOD0=" which is valid but wrong.
Using standard variant in a URL
✗ problem
https://api.example.com/token?data=SGVs+bG8/
✓ correct
https://api.example.com/token?data=SGVs-bG8_
The + and / characters in standard Base64 are reserved in URLs. Either percent-encode them (%2B, %2F) or switch to URL-safe variant in the settings panel, which replaces + with - and / with _.
Encoding non-Latin characters with btoa()
✗ problem
btoa('日本語') → InvalidCharacterError✓ correct
btoa(encodeURIComponent('日本語')) → correctThe browser's btoa() function only handles Latin-1 (characters up to code point 255). Encoding UTF-8 text — emoji, CJK characters, accented letters — requires the encodeURIComponent → btoa dance. Our tool handles this automatically.
Related tools
- Base64 Decoder — Reverse the process — decode strings and files back from Base64 when debugging APIs or email.
- URL Encoder — Percent-encode values before embedding Base64 in query strings or path segments.
Frequently asked questions
What does Base64 encoding do?
Base64 encoding converts binary data or text into a string of 64 printable ASCII characters (A–Z, a–z, 0–9, +, /). It's used whenever binary data needs to travel through a system designed for text — email, URLs, JSON fields, HTTP headers.
Why does Base64 output end with = or ==?
Base64 encodes 3 bytes into 4 characters. When the input length is not a multiple of 3, = padding characters are added to make the output a multiple of 4. One = means 1 padding byte; == means 2. URL-safe Base64 strips the padding entirely.
How much larger does Base64 make my data?
Base64 output is always approximately 33% larger than the original. Three bytes of input produce four Base64 characters. A 100 KB image becomes roughly 133 KB as a Base64 string. The status bar shows you the exact output size.
What is the difference between standard and URL-safe Base64?
Standard Base64 uses + and / as its 62nd and 63rd characters. These are special characters in URLs. URL-safe Base64 (Base64URL, RFC 4648 §5) replaces + with - and / with _, and strips the = padding. Use URL-safe when embedding Base64 in URLs, filenames, or JWT tokens.
What are MIME line breaks?
RFC 2045 (MIME) requires Base64 lines to be no longer than 76 characters, separated by CRLF. Email clients expect this format for attachments. Enable "Every 76 chars (MIME)" in the settings panel when encoding data for email.
Is Base64 encoding the same as encryption?
No. Base64 is encoding, not encryption. Anyone can decode it instantly without a key — the encoded string carries no secrets. HTTP Basic Auth and JWT payloads are Base64-encoded and completely readable. Use TLS (HTTPS) and proper encryption for sensitive data.
Can I encode any file type?
Yes. The file picker and drag-and-drop accept any file type — images, PDFs, fonts, binaries. Image files show a preview alongside the Base64 output so you can verify the encoding before using it.