About Base64 Encoder & Decoder
Base64 Encoder & Decoder converts UTF-8 text to standard Base64 or to the URL-safe Base64URL variant, and decodes either form back to text. The input pane validates as you type, so a payload that cannot possibly be Base64 is flagged before you run the conversion.
Base64 exists to move bytes through channels that only accept printable characters: mail headers, HTTP headers, JSON string fields, URLs. It is a representation, not protection, and the two common alphabets differ in exactly two characters plus the padding rule. Almost every Base64 bug in practice is one of those two differences, or a mismatch about which bytes were encoded in the first place, since Base64 encodes bytes and text only becomes bytes once you choose an encoding.
How to use this developer tool
- Pick Encode to go from text to Base64, or Decode to go the other way.
- Tick the Base64URL checkbox when the value has to survive a URL, a file name, or a JWT segment. The option applies to encoding only.
- Paste the value and watch the status line: in decode mode it tells you whether the input is a plausible Base64 string before you run anything.
- Run the conversion and compare the result with what you expected, character by character for short values.
- Copy the output into the field that needs it, keeping in mind that the receiving system has its own opinion about padding.
Worked example: the two characters that break URLs
A short string with an emoji produces a payload containing both characters where the two alphabets disagree, which makes the difference visible in one conversion.
Build 🚀 now?Standard Base64 : QnVpbGQg8J+agCBub3c/
Base64URL : QnVpbGQg8J-agCBub3c_The text is 15 bytes in UTF-8 because the emoji costs four, and 15 divides by three, so no padding appears. The standard form contains + and /, both of which change meaning inside a URL: + is read as a space by form decoders and / ends a path segment. Base64URL replaces them with - and _.
Base64 against Base64URL
Both alphabets are defined in RFC 4648; sections 4 and 5 differ only in the last two symbols and in how padding is treated.
| Detail | Standard Base64 (RFC 4648 §4) | Base64URL (RFC 4648 §5) |
|---|---|---|
| Value 62 | + | - |
| Value 63 | / | _ |
| Padding | = to a multiple of four | usually omitted |
| Safe in a URL path or query | no | yes |
| Typical users | HTTP Basic auth, MIME, Data URLs, Kubernetes secrets | JWT segments, JWK values, WebAuthn, file names |
| Line breaks | allowed by MIME at 76 characters | not used |
Troubleshooting
Decoding fails on a value that another tool decodes happily.
Why it happens Decoding here runs a strict UTF-8 decoder. If the original bytes were not UTF-8 text at all, a gzip stream, a protobuf message, or Latin-1 text, the byte sequence is not valid UTF-8 and the decode is rejected instead of producing mojibake.
Fix Decide what the bytes really are. Compressed payloads belong in the Gzip tool, images in the Base64 Image tool, and legacy single-byte text needs a decoder that knows the code page.
A token round-trips here but the server rejects it.
Why it happens The two alphabets are not interchangeable. A JWT segment or a JWK value must be Base64URL without padding; an HTTP Basic credential must be standard Base64 with padding.
Fix Match the variant to the consumer: tick Base64URL for anything that travels in a URL or a JWT, and leave it off for Authorization headers and MIME.
A value arrives at the server with spaces where + used to be.
Why it happens Standard Base64 contains +, and application/x-www-form-urlencoded decodes + as a space. Any payload posted through a form or placed in a query string loses those characters.
Fix Use Base64URL, or percent-encode the value with the URL Encoder before putting it into a query string.
The input is marked invalid although it looks like a clean Base64 string.
Why it happens Whitespace is stripped and missing padding is restored automatically, so neither of those is the cause. What remains is a character outside the alphabet or a length that leaves a remainder of one, which no Base64 string can have.
Fix Look for a copied ellipsis, a non-breaking space, a smart quote, or a line of mail quote markers. Re-copy the value from raw output rather than from a rendered page.
When this tool is the right choice
- Building or reading an HTTP Basic Authorization header while testing an API by hand.
- Inspecting a value taken out of a Kubernetes secret, an .env file, or a configuration field that stores text as Base64.
- Producing a URL-safe identifier or state parameter that survives being pasted into a query string.
- Checking that a service encoded non-ASCII text as UTF-8 rather than as some legacy code page.
When to use something else
- Hiding anything. Base64 is a public transformation with no key; use real encryption and a secret manager for confidentiality.
- Reading a whole JWT. The JWT Decoder splits the three segments and renders the time claims for you.
- Binary payloads. Images belong in the Base64 Image tool and compressed data in the Gzip tool, both of which keep the bytes intact instead of forcing them through a text decoder.
Privacy and data handling
Text is encoded with the browser's own TextEncoder and btoa in this tab, and decoding runs through a strict UTF-8 decoder that fails rather than guessing. Nothing is uploaded and nothing is kept after the tab closes. Base64 is trivially reversible, so a token you paste here is exactly as readable as it was before; treat the value itself, not the tool, as the risk.
Related developer tools
Frequently asked questions
What exactly is the difference between Base64 and Base64URL?
Two characters and the padding convention. Base64URL uses - and _ where standard Base64 uses + and /, and normally drops the trailing = signs. Everything else, including the order of the alphabet, is identical.
Do I need the padding characters?
A standard decoder expects the length to be a multiple of four, so keep the = signs unless the consumer is a Base64URL decoder, which usually recomputes the length instead. This tool re-adds missing padding when decoding, so unpadded input is accepted either way.
Is Base64 a form of encryption?
No. There is no key and the transformation is public, so anyone can reverse it in a second. Encoding a password or an API key changes nothing about who can read it.
Why does my text with accents come back broken elsewhere?
Base64 encodes bytes, and the bytes depend on the character encoding. This tool always uses UTF-8. If the other side assumes Latin-1 or GBK, the same payload decodes to different characters.
How much larger does Base64 make my data?
Four characters for every three bytes, so about 33 percent, plus up to two padding characters. MIME-style line breaks every 76 characters add a little more.
Can I encode emoji and Chinese text?
Yes. They are encoded as their UTF-8 bytes, which is why a single emoji adds four bytes and a Chinese character adds three before the 4:3 expansion.