Base64 Encode / Decode
Encode text to Base64 or decode it back, with URL-safe and Unicode support.
Results are provided as is, for general information. Check anything important before relying on it. See the Terms of Use.
About this tool
Base64 turns binary data into text using 64 ASCII characters, which makes it safe to embed in JSON, XML, data URLs and email. This tool encodes plain text to Base64 and decodes it back, using the standard alphabet by default with a URL-safe option, and it handles full Unicode correctly. Decoding tolerates missing padding and stray whitespace, and switches to the URL-safe alphabet automatically when it sees - or _ in the input.
How it works
3 bytes (24 bits) → 4 characters of 6 bits each Alphabet: A–Z a–z 0–9 + / (URL-safe: - and _ instead of + and /) Padding: = fills the last group to a multiple of 4 characters
Base64 turns arbitrary bytes into plain text by reading them 6 bits at a time and mapping each value to one of 64 safe characters. The output is about a third larger than the input. It is an encoding, not encryption: anyone can reverse it.
| Question | Working | Answer |
|---|---|---|
| Encode “Hello, World!” as Base64 | 13 bytes → 18 characters, padded with == | SGVsbG8sIFdvcmxkIQ== |
| Decode “SGVsbG8=” | reverse the 6-bit mapping, drop the padding | Hello |
| Encode “subjects?_d” in URL-safe Base64 | standard encoding, then swap +/ for -_ and drop = | c3ViamVjdHM_X2Q |
When to use it
Questions
Is Base64 encryption?
No. Base64 is an encoding, not encryption — anyone can decode it. Use it to make binary data safe for text-only channels, never to protect secrets.
What is the difference between standard and URL-safe Base64?
They are identical except for two characters: the standard alphabet uses + and /, while the URL-safe variant uses - and _ so the output can appear in URLs without percent-encoding. URL-safe output also drops the trailing = padding.
Why does my URL-safe output have no = signs at the end?
URL-safe Base64 usually omits the padding because = needs escaping in URLs and query strings. The decoder re-adds whatever padding is missing, so both the padded and unpadded forms decode fine.
Why does my decoded text look garbled?
The input was probably encoded with a different character set or is not valid Base64. The tool tolerates missing padding and whitespace, but it cannot recover text that was mangled before encoding.
Why does encoding make my data a third bigger?
Base64 spends four output characters on every three input bytes, because three bytes are 24 bits and 24 bits split into exactly four 6-bit values. That is where the ~33% comes from, plus up to two = padding characters when the input length is not a multiple of three. Nothing can make a Base64 payload smaller — it is a transport format, not a compression scheme.
Will this output work in my code?
Yes — the standard alphabet here is the RFC 4648 alphabet every language's Base64 library produces, so the output drops straight into JSON, headers or config files. One caveat if you decode with JavaScript's atob: it only handles characters up to U+00FF, while this tool encodes full Unicode as UTF-8 first. Text containing emoji or accented characters will not round-trip through naive atob the way it does here.