Embedding small binary data inside text-only formats: data URIs, JSON values, environment variables, YAML strings. Encoding binary tokens (signatures, keys, hashes) for inclusion in URLs, headers, or cookies. Email attachments and SMIME — historic but still alive.

Don't confuse it with encryption. Base64 is reversible by anyone. If the data is sensitive, encrypt it first. UTF-8 round-trips correctly here — non-ASCII (é, 你好, 🚀) goes through TextEncoder / TextDecoder , not btoa / atob directly. Naive btoa(str) in JavaScript breaks on non-Latin characters. Padding — standard Base64 always ends with 0/1/2 = characters depending on input length. base64url often omits them. Decoders that require padding will reject unpadded input; this tool re-adds it on decode if missing. Whitespace inside encoded strings — the decoder here strips spaces and line breaks (common from copy-paste), but some libraries don't, so re-encode if you're piping to one of those.

Base64 is not encryption. The most common misuse: developers Base64-encoding API keys, passwords, or "sensitive" config and treating it as obfuscated. It's reversible in one line of code in any language — atob(str) in the browser, base64.b64decode() in Python. If you need actual secrecy, use AES-GCM or libsodium. Base64 is transport encoding, not security. The size penalty is exactly 4/3 plus padding. 100 bytes of input becomes 136 characters of Base64. For a 1 MB file: 1.37 MB Base64. This is why inline data URIs for images larger than ~4 KB are usually a bad tradeoff — you pay the size penalty, lose browser caching, and the document download grows. See our Base64 article for the full breakdown. Base64 vs base64url. Two different alphabets exist: standard Base64 uses + , / , and = ; base64url uses - , _ , and usually omits padding. JWT tokens, signed URLs, and anything URL-bound uses base64url to avoid characters that need percent-encoding. This tool supports both — pick the right one for the destination. UTF-8 first, then Base64. The order matters. JavaScript's btoa takes a "binary string" (one byte per code unit) and fails on multi-byte characters. The correct pipeline for arbitrary text is UTF-8 encode → Base64 encode . Reversing that order produces output that round-trips for ASCII but corrupts everything else. This tool handles the encode step automatically. For huge files, prefer multipart/form-data. Encoding a 50 MB file as Base64-in-JSON for a single API request is an antipattern: 67 MB request body, CPU spent on the encode step, plus your API gateway probably has a 10 MB limit anyway. HTTP multipart was designed for this; use it.

Base64 Encoder / Decoder

Encode text to Base64 or decode Base64 back to text. UTF-8 safe and base64url variant supported.

Mode

Variant

Input

Output

Enter input above to see the result.

What Base64 actually does

Base64 turns arbitrary bytes into 64 ASCII characters (A–Z, a–z, 0–9 plus two extras). Three input bytes become four output characters, so the result is roughly 33% larger than the input. It's an encoding, not encryption — anyone can decode it.

When to use Base64

Embedding small binary data inside text-only formats: data URIs, JSON values, environment variables, YAML strings.
Encoding binary tokens (signatures, keys, hashes) for inclusion in URLs, headers, or cookies.
Email attachments and SMIME — historic but still alive.

Standard vs base64url

Standard (RFC 4648 §4) uses +, /, =. Fine in email, JSON values, most XML.
base64url (RFC 4648 §5) uses -, _, and typically drops trailing = padding. Used in JWTs, OAuth tokens, and anywhere the value lives in a URL where +///= would need extra escaping.

Common gotchas

Don't confuse it with encryption. Base64 is reversible by anyone. If the data is sensitive, encrypt it first.
UTF-8 round-trips correctly here — non-ASCII (é, 你好, 🚀) goes through TextEncoder/TextDecoder, not btoa/atob directly. Naive btoa(str) in JavaScript breaks on non-Latin characters.
Padding — standard Base64 always ends with 0/1/2 = characters depending on input length. base64url often omits them. Decoders that require padding will reject unpadded input; this tool re-adds it on decode if missing.
Whitespace inside encoded strings — the decoder here strips spaces and line breaks (common from copy-paste), but some libraries don't, so re-encode if you're piping to one of those.

Expert notes

Base64 is not encryption. The most common misuse: developers Base64-encoding API keys, passwords, or "sensitive" config and treating it as obfuscated. It's reversible in one line of code in any language — atob(str) in the browser, base64.b64decode() in Python. If you need actual secrecy, use AES-GCM or libsodium. Base64 is transport encoding, not security.
The size penalty is exactly 4/3 plus padding. 100 bytes of input becomes 136 characters of Base64. For a 1 MB file: 1.37 MB Base64. This is why inline data URIs for images larger than ~4 KB are usually a bad tradeoff — you pay the size penalty, lose browser caching, and the document download grows. See our Base64 article for the full breakdown.
Base64 vs base64url. Two different alphabets exist: standard Base64 uses +, /, and =; base64url uses -, _, and usually omits padding. JWT tokens, signed URLs, and anything URL-bound uses base64url to avoid characters that need percent-encoding. This tool supports both — pick the right one for the destination.
UTF-8 first, then Base64. The order matters. JavaScript's btoa takes a "binary string" (one byte per code unit) and fails on multi-byte characters. The correct pipeline for arbitrary text is UTF-8 encode → Base64 encode. Reversing that order produces output that round-trips for ASCII but corrupts everything else. This tool handles the encode step automatically.
For huge files, prefer multipart/form-data. Encoding a 50 MB file as Base64-in-JSON for a single API request is an antipattern: 67 MB request body, CPU spent on the encode step, plus your API gateway probably has a 10 MB limit anyway. HTTP multipart was designed for this; use it.