Base64 Encoder & Decoder
Encode text to Base64 or decode Base64 back to text. Supports UTF-8 characters.
No data sent to serverRelated Tools
What is Base64 Encoding?
Base64 is a binary-to-text encoding scheme that represents binary data using 64 printable ASCII characters (A-Z, a-z, 0-9, +, /). It is commonly used to embed binary data in text-based formats such as JSON, XML, HTML, and email (MIME).
Base64 encoding increases the data size by approximately 33%, but ensures the data can be safely transmitted through text-only channels without corruption. Common use cases include encoding images as data URIs, transmitting file attachments in emails, and storing binary data in JSON APIs.
This tool handles UTF-8 text correctly, meaning you can encode and decode strings containing non-ASCII characters like emojis, Chinese, Japanese, Korean, and other Unicode characters without data loss.
How to Use
- Paste your plain text (to encode) or Base64 string (to decode) into the input box.
- Click "Encode" to convert text to Base64, or "Decode" to convert Base64 back to text.
- Copy the result with the Copy button or save it with Download.
Real-world use cases
- HTTP Basic Auth:
Authorization: Basic dXNlcjpwYXNzencodesuser:pass - Data URLs: embed small images directly in HTML/CSS —
data:image/png;base64,iVBO... - JWT tokens: three Base64URL-encoded sections joined with dots
- Email attachments (MIME): binary files are Base64-encoded for 7-bit transport
- JSON API binary: when you need to send binary data in a JSON field
- Configuration secrets: some tools accept Base64-encoded values to avoid escaping issues (NOT for security)
Base64 vs Base64URL
Two characters in standard Base64 cause problems in URLs: + (URL-decoded as space) and / (path separator). Base64URL (RFC 4648 §5) replaces them with - and _ respectively, and often drops the trailing = padding. JWT tokens, OAuth state parameters, and API keys all use Base64URL specifically.
Spotting which is which: if you see +, /, or = at the end → standard Base64. If you see - or _ with no padding → Base64URL.
A Way to Move Binary Data Through Text-Only Channels
Base64 exists because a lot of infrastructure was built to carry text and nothing else. Email headers, JSON strings, XML documents, URLs, and configuration files all expect printable characters. Hand them raw binary and something in the chain mangles it — a null byte terminates a string, a control character breaks a parser, a high byte gets mistranslated between character sets.
Base64 solves this by regrouping the data. Three bytes of input become four characters drawn from a 64-character alphabet of letters, digits, plus, and slash — all safely printable. Because four characters carry three bytes, the encoded form is always about 33% larger than the original.
That size penalty is the whole trade. You accept a third more bytes in exchange for data that survives any text channel intact.
Base64 Is Not Encryption, and It Is Not Compression
This needs saying plainly because it causes genuine security incidents. Base64 has no key and no secret. Anyone can decode it instantly — including this page, using no password whatsoever. A Base64-encoded API key in a config file, a Base64-encoded password in a URL, or a Base64 “obfuscated” token in JavaScript are all fully exposed.
It is also not compression. It makes data larger, never smaller. Encoding an already-compressed file adds 33% for no benefit.
The one thing it does well is exactly what it was designed for: making arbitrary bytes safe to place inside text.
Where You Meet It
Data URIs. A small image embedded directly in HTML or CSS as data:image/png;base64,..., saving an HTTP request. Worth it for tiny icons; wasteful for anything substantial, since the 33% penalty applies and the data cannot be cached separately.
Email attachments. MIME has encoded attachments this way since 1992, which is why an email with a 3 MB photo is roughly 4 MB on the wire.
Basic authentication. The username and password are Base64-encoded in the header, which is precisely why it must only ever be used over HTTPS.
JWT tokens. The header and payload are base64url-encoded, which is why they can be read by anyone holding the token.
Certificates and keys. The PEM format wraps Base64 in header and footer lines.
FAQ
Does it support Unicode and emojis?
Yes. This tool uses UTF-8 encoding internally, so characters like accented letters, CJK characters (Korean / Chinese / Japanese), and emojis are fully supported. Try encoding “한글 🎉” to see the result.
Is Base64 encryption?
No. Base64 is an encoding, not encryption. It provides zero security — anyone can decode it. Never use Base64 to “hide” passwords, API keys, or sensitive data. Use proper encryption (AES) or hashing (Argon2, bcrypt) instead.
Why is the encoded output longer than the input?
Base64 maps every 3 bytes (24 bits) to 4 ASCII characters (32 bits, but only 24 useful), giving a 4/3 ratio — about 33% larger. Plus padding when the length isn’t divisible by 3.
Why does decoding sometimes fail?
Most common reasons: (1) the input contains invalid characters (whitespace, line breaks not stripped), (2) padding = was dropped (try adding = until length is a multiple of 4), (3) it’s actually Base64URL with -_ instead of +/ — replace those characters first, then decode.
Can I encode files (not just text)?
This tool handles text only. For files, drag your file to a free file-to-base64 utility, or use the command line: base64 myfile.png > encoded.txt on Mac/Linux, or PowerShell’s [Convert]::ToBase64String on Windows.
What’s the difference between Base64 and hex (Base16)?
Hex uses 2 chars per byte (100% overhead, very readable). Base64 uses ~1.33 chars per byte (33% overhead, less readable). Use hex for human-readable debug (SHA-256 fingerprints), Base64 for compact machine-to-machine transport.
Is Base64 a form of encryption?
No. There is no key and no secret — anyone can decode it instantly. Never use it to hide credentials, tokens, or any other sensitive value.
Why is the encoded text longer than the original?
Three bytes become four characters, so the output is always about 33% larger. That expansion is the cost of making binary data safe for text-only channels.
What is base64url and how is it different?
A variant that replaces plus and slash with hyphen and underscore, and usually drops the padding, so the result is safe inside URLs and filenames. JWTs use it.
Does it handle emoji and non-Latin text?
Yes. Text is converted to UTF-8 bytes before encoding, so any Unicode content round-trips correctly.
What are the equals signs at the end?
Padding. Because the encoding works in groups of three bytes, inputs that do not divide evenly are padded so the output length is a multiple of four.
⚠️ Reference Only
Output is generated based on your input and is provided for reference. Results may vary depending on your specific use case, edge cases, or environment-specific behavior. We do not guarantee accuracy of conversions, validations, or computed values.
Always verify critical outputs against official documentation or production environments. We are not responsible for any decisions or losses based on these tool results.