Base64 Encode and Decode Online — Free Tool

Base64 Encoder & Decoder

Base64 Encoder & Decoder converts any text into Base64 and back. Developers use it for API tokens, data URIs, email attachments and debugging encoded payloads.

Unlike naive tools that corrupt non-English text, this one correctly handles full Unicode — emoji, Urdu, Arabic, Chinese and every other script encode and decode perfectly.

How to use the base64 encoder & decoder

1. Type or paste your input.
2. Click “Encode” to convert text to Base64, or “Decode” to convert Base64 back to text.
3. Copy the result with one click.
4. Chain operations — decode a value, edit the text, and encode it again without leaving the page.

Key features

• Full Unicode support: emoji and non-Latin scripts work correctly.
• Clear errors: malformed Base64 is flagged instead of producing garbage.
• One-click copy: grab long encoded strings instantly.
• Private: encoding runs locally — tokens and secrets never leave your browser.

Embed Images Directly in HTML and CSS

Small icons don’t need separate files: a Base64 string works as a data URI right inside your HTML or CSS, rendering with zero extra requests and speeding up first paint. It’s ideal for tiny assets — large photos should stay as files, since Base64 inflates data by about a third. Encoding URLs instead? The URL encoder handles those, and the hash generator covers checksums.

Full Unicode: Urdu, Arabic, and Emoji Included

Cheap Base64 tools mangle anything beyond plain English — Urdu script, Arabic, and emoji come back as mojibake. This encoder handles the full Unicode range correctly, so what you encode is exactly what you get back on decode. Paste with confidence in any language. That makes it safe for multilingual content, chat messages, and anything copied from social media. Dealing with web addresses full of odd characters? Run them through the URL encoder-decoder instead.

Frequently asked questions

What is Base64 used for?

It represents binary data as plain ASCII text — common in API authentication tokens, embedding images in CSS/HTML (data URIs), and email attachments.

Why do some tools corrupt my Urdu/Arabic text?

They use the browser’s btoa() directly on Unicode, which mangles multi-byte characters. This tool encodes proper UTF-8 bytes first, so every script survives.

Is Base64 encryption?

No — it’s just an encoding, not encryption. Anyone can decode Base64, so never use it to “hide” passwords or secrets.

My decode shows an error — why?

The input probably contains characters outside the Base64 alphabet or has incorrect padding (=). Check for typos or line breaks.

Pro Tips

• Embed small images in HTML/CSS: base64 data-URIs eliminate extra HTTP requests for tiny assets.
• API payloads: safely transport binary data inside JSON, which only supports text.
• Remember: base64 is encoding, not encryption — anyone can decode it. Never use it to “hide” secrets.

More FAQs

Does base64 make files bigger?

Yes — about 33% larger than the original binary. It’s a trade-off for text-safe transport.

Is base64 secure?

No. It’s trivially reversible encoding, not encryption. Use real encryption for sensitive data.

How It Works: Under the Hood

Base64 isn’t encryption or compression — it’s a binary-to-text encoding scheme defined in RFC 4648. It takes any 3 bytes (24 bits) of data and splits them into four 6-bit groups, mapping each group to one of 64 printable ASCII characters (A–Z, a–z, 0–9, +, /). When the input length isn’t divisible by 3, the output is padded with = characters — one = for a 2-byte remainder, two for a 1-byte remainder.

This matters because many systems (JSON, email headers, URLs, HTML attributes) only safely transport plain text. Base64 lets binary data — images, files, cryptographic keys — survive that journey intact. The trade-off: encoded output is roughly 33% larger than the original. Decoding simply reverses the process, and because the mapping is deterministic, any Base64 string decodes to exactly one byte sequence.

Two gotchas worth knowing: standard Base64 uses + and /, which are unsafe in URLs — that’s why a URL-safe variant (RFC 4648 §5) substitutes – and _ instead. And Base64 has no integrity check — a single corrupted character silently produces wrong bytes, so never use it where tampering matters.

Real-World Use Cases

• Embedding images in HTML emails: many email clients block external images. A marketer encodes a 20KB logo as a Base64 data URI (data:image/png;base64,…) so it renders inline with zero external requests.
• Storing binary blobs in JSON APIs: a backend developer needs to send a PDF through a JSON-only API. Base64-encoding the file bytes into a string field is the standard workaround.
• Debugging Basic Auth headers: HTTP Basic Authentication sends username:password as Base64. A developer pastes the header value here to verify which credentials a failing request is actually sending.
• Inspecting JWT-adjacent tokens: while JWTs use the URL-safe variant, standard Base64 decoding still reveals the structure of many legacy session tokens and API keys during debugging.
• Data URIs in CSS: a front-end developer inlines a tiny icon font or 1px spacer directly in a stylesheet, eliminating an HTTP round-trip for a sub-kilobyte asset.

Advanced Tips

• Watch for whitespace corruption: some systems insert line breaks every 76 characters (MIME-style). If decoding fails, strip all whitespace and newlines from the input first — they’re almost never part of the actual encoding.
• Identify the variant before decoding: if the string contains – or _, it’s URL-safe Base64 — convert those back to + and / (and restore any stripped padding) before decoding with a standard decoder.
• Check padding when copying: trailing = characters are easy to lose when double-clicking to select text. Missing padding is the #1 cause of “invalid Base64” errors on otherwise fine strings.
• Estimate sizes fast: multiply the Base64 length by 0.75 to get the approximate original byte size — handy when checking whether an encoded upload will fit a field limit.

Common Mistakes to Avoid

• Treating Base64 as encryption: it provides zero secrecy — anyone can decode it instantly. Never “protect” passwords, tokens, or PII by Base64-encoding them.
• Encoding already-encoded data twice: double-encoding is a classic bug (often from an overzealous middleware layer). If decoded output looks like random alphanumeric soup ending in =, decode it again.
• Ignoring character encoding: Base64 encodes bytes, not characters. Encoding “café” as UTF-8 vs Latin-1 produces different Base64. When text round-trips wrong, the charset — not the Base64 — is the culprit.
• Using standard Base64 in URLs: + becomes a space and / breaks path routing when a Base64 string is pasted raw into a URL. Use the URL-safe variant or percent-encode it.