Base64 & URL Encoder
A Base64 and URL encoding tool. Paste text to get its standard Base64, URL-safe Base64URL, and percent-encoded forms at once, or switch to decode to recover the original — all UTF-8 aware and computed in your browser. Handy for JWTs, data URIs, query strings and API debugging.
Text-only channels need a way to carry binary and awkward characters, and encodings are that way. Base64 packs three bytes into four printable characters, expanding size by about a third in exchange for surviving anything that only tolerates text — email bodies, JSON fields, data URIs, JWT segments. It is not secret and not compressed; it is just a safe costume for bytes.
The URL is a hostile environment for Base64, because +, / and = all mean something in a URL. Base64URL fixes that by substituting - and _ and dropping the padding, which is why it is what JWTs and URL tokens actually use. Separately, percent-encoding (%20, %3D) is the URL’s own escaping for individual components — different tool, different job.
The bug that bites everyone is UTF-8. The naive btoa() chokes on anything beyond Latin-1, so an é or an emoji either throws or silently corrupts. The fix is to convert the string to UTF-8 bytes before Base64-encoding and after decoding — which this tool does for you, showing all three encodings at once so you can copy whichever your context needs. And to be clear: because decoding needs no key, none of this hides anything.
How it works
- Standard Base64, URL-safe Base64URL, and percent-encoding at once.
- Encode and decode directions, both UTF-8 aware.
- Correctly round-trips multibyte characters and emoji.
- Runs fully in your browser — nothing is uploaded.
Frequently asked questions
What is the difference between Base64 and Base64URL?
Both turn binary data into text using 64 printable characters. Standard Base64 uses + and / and pads with =, which is fine in most contexts but breaks inside URLs (+ becomes a space, / is a path separator, = is reserved). Base64URL swaps + for - and / for _ and usually drops the padding, so the result is safe to drop into a URL, a filename, or a JWT segment without further escaping. This tool shows both forms side by side.
Is Base64 encryption?
No. Base64 is an encoding, not encryption — it is fully reversible by anyone with no key, and it exists to represent binary safely as text, not to hide it. Never use Base64 to "protect" a secret; it is trivially decoded (this very tool does it). Its real jobs are embedding binary in text formats: data URIs, email attachments (MIME), JWT segments, and API payloads that must be plain text.
Why does encoding non-ASCII text need care?
The browser’s raw btoa() only handles Latin-1 bytes and throws on characters like é or 😀. The correct approach is to encode the text as UTF-8 bytes first, then Base64 those bytes — and reverse it on the way back. This tool does that automatically, so multibyte and emoji round-trip correctly instead of corrupting, which is a very common bug in hand-rolled encoders.
When do I need URL (percent) encoding instead?
Percent-encoding (%20 for a space, and so on) is for making arbitrary text safe inside a URL — query-string values, path segments, form bodies. It is different from Base64: it only escapes the characters that are unsafe in a URL, leaving the rest readable. Use percent-encoding for URL components, and Base64URL when you need to pack binary or already-encoded data compactly into a URL-safe token.