free_tool
Base64 & URL Encoder / Decoder
Encode and decode base64, base64url and URL strings in one place. Pick a mode, paste your text, and the output updates as you type. UTF-8 is handled properly, so emoji and accents survive the round trip instead of turning into garbage. It runs in your browser, so nothing you paste leaves your machine.
Encoding bugs love to hide in transit: a token that breaks in a query string, double-encoded URLs, base64 that chokes on a unicode character. I build the pipelines and integrations where this kind of thing has to be right the first time.
Wiring up an integration? Book a callBase64 uses TextEncoder for UTF-8 bytes before encoding. Base64URL swaps +/ for -_ and drops padding, then restores it on decode. URL-component uses encodeURIComponent / decodeURIComponent; full URL uses encodeURI.
encode_without_surprises
The encoding you meant, with the bytes intact
Most quick base64 helpers call btoa on the raw string and break the moment you feed them a unicode character, because btoa only speaks Latin-1. This tool encodes to UTF-8 bytes first, so a name with an accent or an emoji in a payload comes back exactly as you put it in.
The other common mix-up is base64 versus base64url. Tokens and URL-safe identifiers use - and _ with no padding, so a plain base64 decoder rejects them. Switch the mode and the alphabet and padding are handled for you, no manual find-and-replace.
faq
Questions & answers
- What is the difference between Base64 and Base64URL?
- Standard Base64 uses the characters + and / and pads with =, which are all unsafe to drop into a URL without escaping. Base64URL (base64url) swaps + and / for - and _ and omits the padding, so the result is safe to put directly in a URL or filename. This tool produces both.
- Why would I use URL-safe Base64?
- Because plain Base64's + / = characters get mangled or percent-encoded inside URLs, query strings and filenames. URL-safe Base64 avoids that entirely, which is why it is the encoding used for JWT segments and many tokens passed in URLs.
- Does it handle unicode and emoji correctly?
- Yes. It encodes text as UTF-8 before Base64, so accented characters, non-Latin scripts and emoji round-trip correctly instead of breaking the way a naive byte-level encoder would. Decoding reverses the same UTF-8 step.
- What is the difference between encodeURI and encodeURIComponent?
- encodeURI is for escaping a whole URL, so it leaves characters like : / ? & = intact because they have meaning in a URL. encodeURIComponent is for a single piece of a URL, like one query-string value, so it escapes those characters too. Use encodeURIComponent when you are inserting a value into a URL and encodeURI when you are cleaning up an entire URL.
- Is Base64 encryption, and is my input sent anywhere?
- No to both. Base64 is encoding, not encryption: it is fully reversible by anyone and provides no secrecy, so never use it to protect data. And all encoding and decoding runs in your browser, so the text you paste is never sent to a server.
Data that breaks somewhere in transit?
Double-encoded URLs, tokens that fail on one service and pass on another, base64 that mangles unicode. I'll make the encoding boundaries in your stack correct and boring. Book a call, or leave your email.
Prefer proof first? See how this plays out in real case studies →