Overview
Introduction
Base64 turns raw bytes into plain ASCII text, just letters, digits, and a few symbols (+, /, =), so it survives being pasted into JSON, a URL, an email body, or an HTTP header without anything getting mangled along the way.
You reach for encoding when you're producing a value, not reading one: building a request header by hand, stuffing a small file into a JSON payload, or getting something into a format that only accepts printable ASCII. This runs locally in your browser, so there's no script to write and no third party seeing your source text.
What Is Base64 Encoder?
Base64 is a binary-to-text scheme: every 3 raw bytes become 4 printable ASCII characters, pulled from a 64-character alphabet. If the last group comes up short, = signs pad it out.
That alphabet is just A-Z, a-z, 0-9, plus + and /. They were picked because they survive systems built only for printable ASCII, unlike raw bytes, which can contain control characters a text-based protocol has no way to represent.
One thing people mix up: Base64 isn't compression, output is always bigger, never smaller, and it isn't encryption either, since there's no key and anyone can reverse it instantly. It's transport encoding, plain and simple: a way to write bytes down as characters a text format won't choke on.
How Base64 Encoder Works
Your text runs through the browser's TextEncoder first to produce UTF-8 bytes, then those bytes get grouped in 3s and mapped through the standard Base64 alphabet using the browser's built-in btoa.
That UTF-8 step isn't optional. btoa on its own only understands Latin1 byte values, so handing it raw multi-byte Unicode either throws an error or mangles the output. Converting to UTF-8 first is what lets emoji, accented letters, and everything else round-trip back to the exact original string.
When To Use Base64 Encoder
Reach for this when you're building a Basic Auth header, dropping a small binary or text blob into JSON, or just want to see what a Base64 string in an API response or JWT actually says.
It's for producing a value, not inspecting one someone else already made: constructing a Basic Auth header for a manual curl call, generating a fixture for a test case, or checking what a given input encodes to before you write that logic yourself.
Often used alongside Base64 Decoder.
Features
Advantages
- Runs entirely in your browser, nothing you paste gets sent anywhere.
- Handles multi-byte Unicode correctly, not just plain ASCII.
- Matches the alphabet and padding rules of every standard Base64 implementation out there.
Limitations
- Output runs about 33% bigger than the input, so this isn't the tool for size-sensitive storage.
- This is standard Base64 (+ and /). Need URL-safe output (- and _)? That's a different, related tool.
Base64 Encoding vs. URL Encoding
| Base64 (this tool) | URL encoding | |
|---|---|---|
| Alphabet used | A-Z, a-z, 0-9, +, /, = | ASCII plus %XX sequences |
| Safe to drop directly into a URL | No, may contain + and / | Yes, that's its purpose |
| Output size vs. input | About 33% larger | Grows only for unsafe characters |
| Typical use | Basic Auth headers, JWTs, embedding binary data | Query strings, form values |
Examples
Best Practices & Notes
Best Practices
- Use Base64 to make binary-safe data transportable as text, never as a stand-in for real encryption.
- Need URL-safe output? Swap + and / for - and _ afterward, or use a URL-safe Base64 variant.
- Decode and compare round-trip output while you're debugging, just to confirm nothing got corrupted in transit.
- Encode the full "username:password" string as one value for Basic Auth headers, not each part separately. The colon is part of what gets encoded.
- For large binary payloads (files, images), reach for a command-line tool or library instead of a browser text field. This tool is built for short values like tokens and headers.
- Generating a fixture for a test that exercises Base64-decoding logic? Do it here instead of hand-typing it. One mistyped character produces different but still valid-looking Base64.
Developer Notes
Internally, this UTF-8 encodes the string via TextEncoder, then walks the resulting byte array building a Latin1 binary string one character code at a time, before handing that string off to the native btoa. That intermediate step exists because btoa only understands Latin1 byte values (0-255 mapped directly to characters); it can't be called with UTF-8 bytes or a raw Unicode string directly, and feeding it either throws or misencodes anything outside the ASCII range. On the decode side, the Base64 decode tool's atob is actually more permissive than this encoder's output style suggests: it treats trailing = padding as optional (the WHATWG forgiving-base64 decode algorithm), even though this encoder always emits it correctly.
Base64 Encoder Use Cases
- Manually constructing a Basic Auth Authorization header for testing an API
- Decoding and re-encoding parts of a JWT to inspect its payload
- Embedding a small text or binary snippet inside a JSON config value
- Generating a Base64 fixture for a unit test that exercises Base64-decoding code
- Preparing the Base64 portion of a small inline data URI for an image or font in CSS or HTML
Common Mistakes
- Assuming Base64 provides any confidentiality, it's trivially reversible by anyone.
- Passing raw non-ASCII text straight to a naive btoa call without UTF-8 encoding first, which throws or produces garbled output.
- Encoding a username and password as two separate Base64 values instead of one colon-joined "username:password" string for a Basic Auth header.
- Assuming Base64 output is safe to drop directly into a URL or filename as-is. + and / are reserved or unusual in those contexts.
Tips
- Going into a URL? Remember standard Base64's + and / aren't URL-safe on their own.
- Paste the output into the Base64 decode tool to visually confirm the round-trip before you use it elsewhere.
- Count the trailing = characters as a quick sanity check: two means the input length was 1 more than a multiple of 3, one means 2 more, none means it was already a multiple of 3.