الأدوات · النصوص · ترميز وفك ترميز ⁨Base64⁩ · الأدلة · How to Encode and Decode Base64 Text, Correctly for Any Language

How to Encode and Decode Base64 Text, Correctly for Any Language

4 دقيقة قراءة

Paste text into the Base64 tool, choose Encode or Decode, and the result appears immediately - no Run button, no file, nothing uploaded. The one detail worth knowing before you use it on anything beyond plain English: a naive Base64 implementation breaks on non-Latin text, and this one is built specifically not to.

Text, encode or decode, live result A three-step flow: paste text or Base64 into the box, choose Encode or Decode with an optional URL-safe checkbox, and the converted result appears live with a copy button. paste text or Base64 Encode / Decode + URL-safe option live result
Every keystroke and every option change re-runs the conversion.

Why non-Latin text needs more than the browser's raw btoa

The browser's native btoa() function throws an error on any character above Latin-1, which includes every Arabic character; accented letters such as é, ü or ñ sit inside Latin-1, so btoa accepts them but encodes their Latin-1 byte rather than UTF-8, which other systems then decode as the wrong text. A tool built by calling btoa directly on whatever you type will work for plain English input, fail outright on Arabic text and quietly mis-encode accented letters - the kind of gap that passes casual testing and breaks for a real fraction of actual users. This tool never calls btoa on your text directly: it first converts the text to UTF-8 bytes, then Base64-encodes those bytes, so any script your keyboard can type encodes and decodes correctly, byte for byte.

Encode and Decode

Encode takes whatever text you type or paste and produces standard Base64. Decode takes a Base64 string and reverses it back to the original text. If the pasted string is not valid Base64 - a stray character, an impossible length, bytes that don't form valid UTF-8 - the tool shows a clear message rather than silently producing garbled text with invisible replacement characters standing in for whatever it couldn't decode.

As a concrete check: encoding the Arabic word مرحبا (hello) produces 2YXYsdit2KjYpw==, and decoding that string back returns the exact original word, letter for letter. A plain btoa("مرحبا") call, with no UTF-8 step first, throws an error instead - which is exactly the gap this tool's own UTF-8 conversion step exists to close, not a theoretical edge case.

The invalid-input check is stricter than it might look at first. A Base64 string can be made of entirely legal Base64 characters and still not represent valid UTF-8 once decoded back to bytes - a corrupted copy-paste, or Base64 that was never text to begin with. Rather than quietly replacing whatever doesn't decode cleanly with an invisible placeholder character, decoding here fails outright and reports it, so a broken result never looks like a correct one.

The URL-safe option

Standard Base64 uses +, / and = padding, all three of which have special meaning inside a URL and need extra encoding to sit inside one safely. The URL-safe checkbox switches to the RFC 4648 variant used in JWTs and URL query values: + becomes -, / becomes _, and the trailing = padding is dropped entirely, with padding recalculated automatically on decode so you never have to add it back by hand. Decode reads both alphabets, so the checkbox only shapes what Encode writes.

What it handles without you noticing

Base64 wrapped across multiple lines - common in email and older config formats - decodes correctly because embedded line breaks are stripped before the conversion runs. Missing padding on an otherwise-valid string, common when Base64 has been copied out of a URL, is normalized automatically rather than rejected. And input is capped at 2,000,000 characters, well past anything this text tool is meant for - a small API key, a config value, a JWT segment - past which a one-time notice appears without truncating anything you've typed.

There's also a real, easy-to-hit browser limit this tool routes around without you noticing it: converting bytes to Base64 by handing them to the browser's string functions in one giant call can overflow the JavaScript engine's own argument-stack limit once an input reaches a few hundred kilobytes - a genuine crash, not a slowdown. Encoding here processes bytes in 32,768-byte chunks specifically to stay under that limit, so a large paste - well past typical API-key or config-value size - encodes correctly instead of failing partway through with an error that has nothing obviously to do with the size of what you pasted.

For why treating a Base64 string as a secret is a real mistake, not a small one, see the broader reasoning. To decode a real JWT payload as a worked example, see the use-case guide.

Nothing typed here is uploaded, in either mode - the conversion runs entirely on your device.

جرّب ⁨ترميز وفك ترميز ⁨Base64⁩⁩ مجانًا ترميز وفك ترميز ⁨Base64⁩

أدوات ذات صلة