Base64 Encoder/Decoder

Base64 encoder and decoder

Encode text to Base64 and decode Base64 back to text, instantly and in your browser. Nothing is uploaded — the conversion happens locally — so you can safely work with tokens, keys, or any sensitive string.

What Base64 is for

Base64 represents binary data using only 64 plain ASCII characters, so it can travel safely through systems built for text: email attachments, JSON and XML payloads, data URLs in CSS or HTML, JWT tokens, and HTTP headers. It is an encoding, not encryption — anyone can decode it — so it protects data integrity in transit, not secrecy. Never use Base64 to hide passwords or secrets.

Encoding inflates size

Base64 turns every 3 bytes into 4 characters, so the encoded result is about 33 percent larger than the original. That is the cost of making binary data safe for text-only channels. It is also why large images embedded as Base64 data URLs bloat a page and should be used sparingly.

Common uses

Embed a small icon directly in CSS as a data URL, decode the payload of a JWT to inspect its claims, or encode credentials for a Basic Auth header. To inspect a decoded JWT payload, pair this with the JSON formatter; for URL-safe text, see the URL encoder.

What Is Base64 Encoding

Base64 encoding converts binary data into a text-safe ASCII string format using a 64-character alphabet (A-Z, a-z, 0-9, +, /). This encoding allows binary content—images, files, cryptographic keys, and arbitrary byte sequences—to be transmitted through text-based systems like email (MIME), JSON APIs, HTML data URIs, and HTTP headers that cannot handle raw binary data.

Base64 is not encryption. It provides no security whatsoever—any Base64 string can be decoded instantly by anyone. Its purpose is purely representational: converting binary to text and back without data loss. The encoding increases data size by approximately 33% (every 3 bytes of input become 4 bytes of output), which is the trade-off for universal text compatibility.

How Base64 Encoding Works

Base64 converts data in 3-byte (24-bit) groups:

1. Take 3 bytes of input (24 bits total)
2. Split into 4 groups of 6 bits each
3. Map each 6-bit value to the Base64 alphabet (A=0, B=1, ..., Z=25, a=26, ..., z=51, 0=52, ..., 9=61, +=62, /=63)
4. Pad with = if the input isn't a multiple of 3 bytes

Example: "Hi" (2 bytes: 0x48 0x69)

• Binary: 01001000 01101001
• Split into 6-bit groups: 010010 000110 1001(00)
• Base64 values: 18, 6, 36 → S, G, k
• With padding: SGk=

Variants:

• Standard Base64: Uses + and / (RFC 4648)
• URL-safe Base64: Uses - and _ instead (safe in URLs without percent-encoding)
• Base64 without padding: Omits trailing = characters (used in JWTs)

Common Use Cases

• Data URIs: Embed images directly in HTML/CSS as data:image/png;base64,...
• Email attachments: MIME encoding converts binary attachments to Base64 for email transport
• API payloads: Transmit binary data (files, images) within JSON request/response bodies
• Authentication headers: HTTP Basic Auth encodes username:password in Base64
• Cryptographic values: Encode keys, certificates, and hashes in text-safe format for configuration files

Best Practices

1. Never use Base64 as a security measure — It is trivially reversible; it provides encoding, not encryption
2. Use URL-safe Base64 for URLs and filenames — The standard + and / characters cause issues in URLs and file systems
3. Consider the 33% size overhead — Base64 increases data size by one-third; for large files, consider binary transfer instead
4. Strip padding when optional — JWT tokens and some APIs use unpadded Base64; know your consumer's requirements
5. Validate before decoding — Check for valid Base64 characters and correct padding to avoid decoding errors