Base64 Encoder & Decoder
Encode text and files to Base64, decode Base64 strings, generate data URIs, and more. Supports URL-safe Base64, MIME line-wrap, and live processing.
Press Ctrl + Enter to encode/decode instantly · All processing is local, your data never leaves your device
What Is the Base64 Encoder & Decoder?
Base64 is a binary-to-text encoding scheme that converts arbitrary binary data, bytes, images, files, encryption keys, into a stream of printable ASCII characters. The name comes from using exactly 64 printable characters as the encoding alphabet (A–Z, a–z, 0–9, +, /). Because 2⁶ = 64, every character encodes exactly 6 bits, and every 3 input bytes (24 bits) map to exactly 4 Base64 characters.
The core reason Base64 exists is that many systems, email protocols, HTTP headers, XML, JSON, URLs, were designed to carry text, not raw binary. Sending raw bytes through these channels often causes data corruption or protocol errors. Base64 eliminates that risk: since the output only uses 64 safe printable characters, it passes through any text-based pipeline intact. The trade-off is a 33 % size increase, which is acceptable for most practical payloads.
URL-safe Base64 is a variant that replaces the two non-URL-safe characters in the standard alphabet (+ becomes - and / becomes _) and optionally removes padding = signs. This variant is used in JSON Web Tokens (JWT), OAuth tokens, and anywhere the encoded string appears in a URL query parameter.
Formula
3 bytes (24 bits)24 bits → four 6-bit groupsEach 6-bit value → alphabet[index]4 Base64 characters= added if input % 3 ≠ 0⌈n / 3⌉ × 4 chars⌊length × 3 / 4⌋ bytes(4/3) − 1 ≈ 33.3 %+ → − | / → _ | = removedHow to Use
Text Encoder / Decoder tab
- 1Choose direction: Select Encode (text → Base64) or Decode (Base64 → text) using the toggle at the top.
- 2Set options: Enable URL-safe mode to replace +/ with -_ for use in URLs. Enable Wrap at 76 chars to format output for MIME or email standards. Live mode processes as you type, disable it for very large inputs.
- 3Enter input: Type or paste your text (for encoding) or Base64 string (for decoding). Unicode and multi-line input are fully supported.
- 4Click an example: Use the quick-load buttons to instantly populate the input with a real-world sample such as a JSON payload, JWT header, or HTML snippet.
- 5Copy or download output: Use Copy to copy to clipboard, Download .txt to save as a file, or Copy data URI to get a
data:text/plain;base64,…string for use in HTML or CSS. - 6Swap: Click Swap ↔ to move the output back to the input and flip the direction, useful for verifying a round-trip encode → decode.
File Encoder tab
- 1Open File Encoder: Click the File Encoder tab. Any file type is supported (images, PDFs, audio, fonts, etc.) up to 10 MB.
- 2Upload the file: Drag and drop a file onto the drop zone, or click it to open the file browser. The file is read entirely in your browser, nothing is sent to a server.
- 3View results: The tool shows file name, MIME type, original size, Base64 output length, and size overhead. For image files, a live preview is rendered directly from the Base64 data URI.
- 4Copy or download: Use Copy Base64 for the raw string, Copy data URI for the full embeddable URI, or Download .txt to save the Base64 output as a text file.
Example Calculation
Example 1, Encoding “Man” (the classic 3-byte walk-through)
Input: Man (3 bytes: M=77, a=97, n=110)
Binary: 01001101 01100001 01101110
Group into 6-bit chunks: 010011 010110 000101 101110
Decimal: 19 22 5 46
Alphabet: T W F u
Result: TWFu (no padding, input was exactly 3 bytes)
Example 2, Padding when input is not a multiple of 3
Input "A" (1 byte): 01000001 + 0000 00000000 (16 zero padding bits)
6-bit groups: 010000 010000 (pad) (pad)
Alphabet: Q Q = =
Result: QQ== (two = padding chars)
―
Input "Ma" (2 bytes): 01001101 01100001 + 00000000 (8 zero padding bits)
6-bit groups: 010011 010110 000100 (pad)
Alphabet: T W E =
Result: TWE= (one = padding char)
Example 3, Encoding the JWT header (real-world use case)
JSON: {"alg":"HS256","typ":"JWT"}
URL-safe Base64 (no padding): eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Decode it back → {"alg":"HS256","typ":"JWT"}
This is the first segment of every JWT, the header. It's not encrypted, just Base64url-encoded. Anyone can decode it.
Example 4, Overhead comparison
| Input | Bytes | Base64 length | Overhead |
|---|---|---|---|
| "Hello" | 5 | 8 (SGVsbG8=) | +60.0 % |
| "Hello, World!" | 13 | 20 (SGVsbG8sIFdvcmxkIQ==) | +53.8 % |
| 100-byte input | 100 | 136 chars | +36.0 % |
| 1 000-byte input | 1 000 | 1 336 chars | +33.6 % |
| 1 MB image | 1 048 576 | 1 398 102 chars | ≈ +33.3 % |
Overhead converges to exactly 33.3 % as input grows, because the padding effect on the last group becomes negligible. Small inputs have higher apparent overhead due to padding characters.
Understanding Base64 Encoder & Decoder
What Is Base64 Encoding?
Base64 is a binary-to-text encoding scheme standardised in RFC 4648. It converts any sequence of bytes, raw binary, text, images, executable code, into a string of 64 printable ASCII characters. The alphabet consists of the uppercase letters A–Z (values 0–25), lowercase letters a–z (26–51), digits 0–9 (52–61), plus + (62) and / (63). A 65th character, =, is used exclusively for padding.
The fundamental motivation for Base64 is compatibility. Email protocols (SMTP), HTTP headers, XML, JSON, and many other text-based systems were designed to carry human-readable characters. Raw binary bytes, values 0–255, include control characters that some systems interpret as commands (null bytes, carriage returns, escape sequences). Base64 guarantees the output contains only characters that any text-based system can safely transmit.
Key insight: Base64 does not compress, encrypt, or protect data. It only re-encodes binary data into a safe printable form. The 33 % size increase is the price of that compatibility.
How the Base64 Algorithm Works
The encoding process works on 3-byte groups. Each group of 3 bytes provides 24 bits, which are split into four 6-bit chunks. Since 2⁶ = 64, each 6-bit chunk maps directly to one character in the 64-character alphabet. The result is always 4 output characters per 3 input bytes.
Input bytes: M a n
ASCII values: 77 97 110
Binary (8-bit): 01001101 01100001 01101110
Split to 6-bit: 010011 010110 000101 101110
Decimal: 19 22 5 46
Base64 chars: T W F u
Output: TWFu
When the input length is not a multiple of 3, zero bits are appended to complete the last group, and = padding characters are added so the total output length is always a multiple of 4. One = means one byte was short; two == means two bytes were short.
The Base64 Alphabet Table
| Range | Characters | Index values | Character count |
|---|---|---|---|
| Uppercase | A B C … Z | 0 – 25 | 26 |
| Lowercase | a b c … z | 26 – 51 | 26 |
| Digits | 0 1 2 … 9 | 52 – 61 | 10 |
| Standard symbols | + / | 62, 63 | 2 |
| URL-safe symbols | - _ | 62, 63 (alternate) | 2 |
| Padding | = | N/A | 1 (not an alphabet value) |
Standard Base64 vs URL-Safe Base64
The two characters that differ between the standard and URL-safe variants are the ones that have reserved meanings in URLs: + encodes a space in form data, and / is the path separator. Placing standard Base64 inside a URL would require percent-encoding those characters (%2B and %2F), bloating the URL. URL-safe Base64 (Base64url) solves this cleanly:
| Property | Standard Base64 | URL-safe Base64 (Base64url) |
|---|---|---|
| Symbols | + / | - _ |
| Padding | = required | = usually omitted |
| URL-safe | No (needs percent-encoding) | Yes |
| Used in | MIME email, PEM files, data URIs | JWT, OAuth, URL parameters, cookies |
| RFC | RFC 4648 §4 | RFC 4648 §5 |
This tool supports both variants. Enable the URL-safe toggle to produce Base64url output, and the decoder automatically accepts both formats.
Common Real-World Use Cases
- Data URIs (inline images and fonts): Instead of a separate HTTP request, small images and web fonts can be embedded directly in HTML or CSS as
data:image/png;base64,…. This reduces requests but increases document size, best reserved for icons under 5 KB. - JSON Web Tokens (JWT): A JWT consists of three Base64url-encoded segments separated by dots: header.payload.signature. The header and payload are plain JSON, anyone can decode them. Only the signature provides integrity. Our ASCII Value Calculator can help inspect the character-level encoding of any JWT segment.
- HTTP Basic Authentication: The
Authorizationheader sends credentials asBasic Base64(username:password). This is NOT secure without HTTPS, Base64 is trivially reversible. - Email attachments (MIME): SMTP is a text protocol. Email clients encode binary attachments as Base64 (wrapped at 76 chars per line per RFC 2045) inside the email body, then decode them on receipt.
- PEM certificate files: SSL/TLS private keys, certificates, and certificate signing requests (CSRs) are stored as Base64-encoded DER data between
-----BEGIN CERTIFICATE-----and-----END CERTIFICATE-----markers. - Cryptographic key storage: AES keys, HMAC secrets, and other binary keys are often distributed as Base64 strings because they are compact, printable, and easy to paste into configuration files or environment variables.
Size Overhead and When It Matters
The 33 % overhead of Base64 is fixed and unavoidable. For most small payloads, API tokens, short texts, small configuration blobs, this overhead is negligible. But for large binary assets the cost adds up:
- When overhead is acceptable: Embedding a 2 KB favicon as a data URI (becomes ~2.7 KB), storing a 256-bit encryption key as a Base64 string (becomes ~45 chars), transmitting a small JSON payload via email.
- When overhead matters: Embedding a 500 KB hero image as a Base64 data URI (becomes ~668 KB) is rarely worth it, serve it as a regular file from a CDN instead. The browser cannot cache an inline data URI separately.
- Compression + Base64: Apply gzip or Brotli compression before encoding. Compressed binary encoded as Base64 can still come out smaller than the uncompressed original for text-heavy files.
Base64 and Security, What You Need to Know
Because Base64 is fully reversible without any key, it provides no security by itself. Seeing a Base64 string in a log, URL, or API response does not mean the data is secret, it means it is encoded for transport compatibility.
- Do not use Base64 as obfuscation for sensitive values. Any developer can decode it in seconds.
- Do not store passwords Base64-encoded. Hash passwords with bcrypt, Argon2, or scrypt. Base64 is not a hash.
- Safe usage: Encoding already-encrypted ciphertext as Base64 for transport is correct. The security comes from the encryption, not the Base64 layer.
A JWT's header and payload are Base64url-encoded, they are readable by anyone. Only the signature guarantees integrity, and only if the verification step is implemented correctly on the server.
Decoding Base64, How It Works in Reverse
Decoding reverses the process: each Base64 character is looked up in the alphabet table to recover its 6-bit value. Four Base64 characters are collected to form 24 bits, which are split back into three bytes. Padding characters are discarded; they only signal how many trailing zero bits were appended during encoding. This decoder also automatically normalises URL-safe characters (- → +, _ → /) and handles missing padding, so it accepts all common Base64 variants.
Frequently Asked Questions
What is Base64 used for in real projects?
Base64 shows up in a surprising number of places:
- Email attachments, MIME encodes binary files (PDFs, images) as Base64 inside text-based email messages.
- Data URIs, embed images or fonts directly in HTML/CSS as data:image/png;base64,… without a separate HTTP request.
- JSON Web Tokens (JWT), the header and payload are Base64url-encoded (not encrypted) for safe transport in HTTP headers and URLs.
- HTTP Basic Auth, credentials are sent as Base64("username:password") in the Authorization header.
- API tokens and secrets, many platforms issue credentials as Base64-encoded strings for compact, safe transmission.
- PEM certificate files, SSL/TLS certificates, private keys, and CSRs are Base64-encoded DER data between BEGIN/END marker lines.
Why does Base64 output end with = or ==?
Base64 processes input in 3-byte groups. Each group produces exactly 4 Base64 characters. When the input length is not a multiple of 3, the last group is shorter than 3 bytes:
Input % 3 = 0 → no padding (perfect fit)Input % 3 = 1 → two padding = characters added (one real byte, three Base64 chars padded to four)Input % 3 = 2 → one padding = character added (two real bytes, three Base64 chars padded to four)
Padding makes the output length always a multiple of 4, which simplifies decoding.
Is Base64 the same as encryption?
No, Base64 is encoding, not encryption. The difference is critical:
- Encoding is reversible by anyone without a key. Base64 can be decoded instantly by any tool.
- Encryption is reversible only by someone holding the correct key.
- Base64 provides zero confidentiality, it is merely a way to represent binary data as text.
Never use Base64 alone to protect sensitive data. Use proper encryption (AES, RSA, etc.) and only use Base64 as a transport encoding on top of already-encrypted ciphertext.
What is URL-safe Base64 and when should I use it?
Standard Base64 uses two characters, + and /, that have reserved meaning in URLs. Including them in a URL query string causes ambiguity or breaks routing.
URL-safe Base64 (also called Base64url) makes two substitutions:
+ is replaced with - (hyphen)/ is replaced with _ (underscore)= padding is usually omitted (since % signs in URLs would also need encoding)
Use URL-safe Base64 whenever the encoded string appears in a URL path or query parameter, in a JWT, or anywhere + and / might be misinterpreted.
How much does Base64 increase file size?
Base64 increases size by approximately 33 % for large inputs. The exact factor is 4/3, every 3 input bytes become 4 output characters.
- Small inputs appear to have higher overhead due to padding characters.
- A 1 MB image becomes roughly 1.37 MB as a Base64 string.
- MIME line wrapping at 76 characters adds a small additional overhead (line break characters).
For embedding small icons as data URIs this overhead is usually acceptable. For large media files, serve them via a CDN rather than embedding as Base64.
Can I encode image files to Base64 with this tool?
Yes. Switch to the File Encoder tab and drop any image file (PNG, JPG, SVG, GIF, WebP, etc.) onto the upload zone.
- The tool reads the file in your browser and produces the Base64 string instantly.
- A live image preview is rendered directly from the Base64 data URI so you can verify it.
- Copy the data URI (data:image/png;base64,…) and paste it into CSS background-image or an HTML src attribute to embed the image without an HTTP request.
What is the "Wrap at 76 chars" option?
The MIME standard (RFC 2045) requires that Base64-encoded content in email be broken into lines of no more than 76 characters, each terminated with a CRLF line break.
- Enabling "Wrap at 76" automatically inserts newlines every 76 characters in the output.
- This is required for email attachments but should be disabled for JWT, data URIs, or any context where the Base64 must be a single unbroken string.
- The wrapping has no effect on decodability, a decoder strips whitespace before processing.
Why is my decoded output showing garbled text?
There are several common reasons:
- The original data was binary (an image, PDF, or other non-text file), not UTF-8 text. Decoding binary data as text always produces garbled output, it is the expected behaviour.
- The Base64 string was truncated or has extra characters. Even a single missing or extra character breaks the entire output.
- The encoding was URL-safe (using - and _) but you pasted it into standard mode. This tool automatically normalises URL-safe characters, but some tools do not.
- Padding characters (=) were stripped before you pasted. The tool adds them back automatically, but the result may differ if the original was malformed.