Base64 Encoder & Decoder

What it does

A free base64 encoder and decoder. Works in both directions, handles UTF-8 correctly (emojis, accented characters, non-Latin scripts). Everything runs locally in your browser, so you can paste API tokens, JWT payloads, or sensitive identifiers without sending them to a server. Built on the browser’s native btoa() and atob() with UTF-8 wrappers — same algorithm every modern browser implements.

Base64 encodes binary data using only 64 ASCII characters (A-Z, a-z, 0-9, +, /), with ‘=’ padding to make output length a multiple of 4. The cost is 33% size inflation: 100 bytes of binary becomes 134 bytes of base64. The benefit is that the output is safe to embed in URLs, email bodies, JSON strings, XML, JavaScript source — anywhere binary bytes would break the surrounding format. RFC 4648 defines the standard. Variants exist: Base64URL (replaces + with -, / with _) for URL-safe encoding used in JWTs, and MIME Base64 for email with specific line-length wrapping.

Common uses: embedding small images in CSS or HTML as data URIs (icons, sprites), encoding binary data in JSON API payloads (file uploads, signatures), Basic Auth headers (‘Authorization: Basic <base64(user:password)>’), JWT token decoding to inspect claims, MIME email attachments, and obfuscating data in URLs (note: this is encoding, NOT encryption — anyone can decode it). For larger binary uploads, use multipart/form-data or signed URLs to S3/R2/GCS instead of inflating via Base64.

How to use it

1. Paste text in the input.
2. Click Encode to convert to base64.
3. Click Decode to convert back to plain text.
4. Copy the result with one click.

How it works

Key takeaways

• Base64 is encoding, not encryption — anyone can decode it instantly. Never use it to “hide” passwords or tokens.
• Output is 33% larger than input (4 chars per 3 bytes). HTTP gzip/brotli typically recovers most of that on transmission.
• Base64 vs Base64URL: JWTs use the URL variant (- and _ replace + and /); standard APIs use classic Base64.
• For files over ~100KB, use multipart/form-data uploads or signed-URL uploads (S3, R2, GCS) instead of Base64 inlining — the size penalty plus client-side encode CPU adds up.

Browser’s native btoa() + atob() with a UTF-8 wrapper for non-ASCII (the raw functions only handle Latin-1). RFC 4648 standard: A-Z + a-z + 0-9 + “+/” with “=” padding.

Advanced: Base64 vs Base64URL + size implications

Two variants matter. Base64: classic with “+/” characters. Base64URL: replaces “+” with “-” and “/” with “_” for URL safety. JWTs use Base64URL. Decoding mixed input requires checking which variant. Size cost: 33% inflation (4 output chars per 3 input bytes). Modern compression (gzip/brotli) recovers most of this on HTTP transmission, but URL-embedded Base64 stays inflated. See the JWT decoder for a related token-decoding tool and the Base64 glossary entry.

How this compares to alternatives

vs Linux base64 CLI: identical RFC 4648 output; CLI handles streaming for large files. vs Python base64.b64encode(): same encoding; Python returns bytes, JavaScript returns a string. vs decoding sites that send data to a server: many free sites log Base64 input. We never transmit your data. View Network tab in DevTools to verify.

Common mistakes when using this tool

• Treating Base64 as encryption. It’s reversible by anyone. Use AES or similar for actual confidentiality.
• Mixing Base64 and Base64URL. JWTs and URL-embedded data use URL variant; standard APIs use classic. Convert by replacing chars before decoding.
• Forgetting padding. = padding to make length multiple of 4 is required by some strict decoders, optional in others. Standard says required; tolerate missing if you control both ends.
• Using Base64 for large binary uploads. 33% size penalty + client-side encode CPU cost. Use multipart/form-data or signed-URL uploads (S3, R2, GCS) for files over 100KB.

Learn more about Base64

• Base64 vs Base64URL — the two variants, when each is required, and how to convert between them.
• Data URI images — when to inline images as Base64 vs serve them as files, with size break-even math.
• JWT token structure — the header.payload.signature anatomy and why JWTs use Base64URL specifically.
• JWT glossary entry — the short definition and how JWTs differ from session cookies.

When to use this tool

• Any time text/binary data must travel through a text-only channel (JSON, URL, email).
• Debugging API responses that include base64 blobs.
• Building HTTP Basic Auth headers manually.

When not to use it

• As encryption or obfuscation — base64 is trivially reversible, not secure.
• For large binary files (base64 inflates size by ~33%; use real uploads instead).
• When your language/runtime already has a built-in encoder — use that for production code.

Common use cases

• Embedding small images in CSS as data URIs.
• Decoding the payload of a JWT to inspect claims (without verifying the signature).
• Encoding binary data for safe transport in JSON APIs.
• Generating Basic Auth headers for testing an API.