Base64 Encoder & Decoder
Convert text to Base64 or decode a Base64 string back to text. Unicode and emoji round-trip correctly. Everything runs in your browser, nothing you type is sent anywhere.
What Base64 is for
Base64 solves a specific problem: moving binary data through channels that only reliably handle text. Email headers, JSON strings, XML documents, URLs, and HTTP headers were all designed around printable characters. Raw binary sent through them can be corrupted by encoding conversions, interpreted as control characters, or rejected outright.
Base64 re-expresses any byte sequence using only 64 characters that survive
such channels intact: A-Z, a-z, 0-9,
plus + and /, with = as padding.
The cost is size. Base64 output is about 33% larger than the input, since every 3 bytes become 4 characters. That overhead is the price of transportability, which is why Base64 is used for embedding and transport rather than for storage.
How the encoding works
Base64 processes the input in groups of 3 bytes, which is 24 bits. Those 24 bits are re-split into four 6-bit groups, and each 6-bit value (0 to 63) selects one character from the alphabet.
Encoding the word Man:
- ASCII bytes: 77, 97, 110
- As bits:
01001101 01100001 01101110 - Regrouped into six-bit chunks:
010011 010110 000101 101110 - As numbers: 19, 22, 5, 46
- Mapped to the alphabet: TWFu
When the input length is not a multiple of 3, the final group is padded
with = so the output length stays a multiple of 4. One leftover
byte produces two padding characters, two leftover bytes produce one.
Base64 is not encryption
This is the most consequential misunderstanding about Base64, and it causes real security incidents.
Base64 has no key and no secret. Anyone who sees the string can decode it in seconds, including with this very page. Encoding a password, an API token, or personal data in Base64 provides zero protection, it only makes the value non-obvious to a casual glance.
A frequent example: HTTP Basic Authentication sends credentials as
Base64(username:password). That is not a security measure, it is
purely a transport encoding. Basic Auth is only safe over HTTPS, where TLS
provides the actual protection. Over plain HTTP the credentials are
effectively sent in the clear.
If you need secrecy, use encryption. If you need integrity, use a signature or MAC. Base64 addresses neither.
Examples
| Input | Base64 | Note |
|---|---|---|
Man | TWFu | 3 bytes, no padding needed |
Ma | TWE= | 2 bytes, one padding character |
M | TQ== | 1 byte, two padding characters |
hello | aGVsbG8= | |
Hello, World! | SGVsbG8sIFdvcmxkIQ== | |
{"id":1} | eyJpZCI6MX0= | JSON embedded in a string field |
| (empty string) | (empty string) | Valid, encodes to nothing |
Base64 and base64url
Standard Base64 uses + and /, both of which have
special meaning in URLs: + can be interpreted as a space, and
/ is a path separator. The padding = is also
awkward in query strings.
base64url is a variant defined for exactly this case. It
substitutes - for +, _ for
/, and usually omits padding entirely.
| Position | Standard Base64 | base64url |
|---|---|---|
| Character 62 | + | - |
| Character 63 | / | _ |
| Padding | = | usually omitted |
JSON Web Tokens use base64url, which is why JWT strings contain
- and _ but never +, /, or
=. If a decoder rejects a token, a mismatch between the two
variants is a likely cause. To inspect a token's contents, use the
JWT decoder.
Common use cases
Data URIs in HTML and CSS
Small images can be embedded directly in a page rather than loaded as
separate files:
<img src="data:image/png;base64,iVBORw0KGgo...">. This
eliminates an HTTP request, which is useful for tiny icons. For larger images
it backfires, since the 33% size increase and the loss of separate caching
outweigh the saved request.
Email attachments
MIME uses Base64 to carry attachments through mail systems that were originally text-only. This is the oldest widespread use of the encoding and the reason email attachments are roughly a third larger in transit than the original file.
API tokens and configuration
Binary keys, certificates, and configuration blobs are frequently Base64-encoded so they fit in JSON or environment variables. PEM certificate files are Base64 with header and footer lines wrapped around them.
Storing binary in JSON
JSON has no binary type, so binary payloads inside JSON documents are conventionally Base64 strings. The same applies to XML.
Frequently asked questions
Is Base64 encryption?
No. It is a reversible encoding with no key. Anyone can decode it. Never use it to protect sensitive data.
Why does the output end with =?
Because Base64 encodes 3 bytes at a time into 4 characters. When the input
length is not divisible by 3, = pads the final group so the
output length remains a multiple of 4.
Does this work with Unicode and emoji?
Yes. Input is UTF-8 encoded before Base64 conversion, so non-ASCII characters round-trip correctly in both directions.
Why is my Base64 string 33% larger than the original?
Because 3 bytes of input become 4 characters of output, a ratio of 4/3. This overhead is inherent to the encoding and cannot be avoided.
What is the difference between Base64 and base64url?
base64url replaces + with - and /
with _, and typically drops padding, so the result is safe in
URLs and filenames. JWTs use base64url.
Can I decode any Base64 string here?
Any string that decodes to valid UTF-8 text will display correctly. Base64 representing raw binary data such as an image will produce unreadable characters, since there is no text to show.
Is my input sent to a server?
No. Encoding and decoding happen entirely in your browser via JavaScript. Nothing is transmitted or stored, which matters when inspecting tokens or credentials.
Related tools
- URL encoder and decoder, for percent-encoding in URLs
- JWT decoder, which decodes base64url token segments
- Hash generator, for one-way hashing rather than reversible encoding
- All developer tools