URL Encoder/Decoder & Base64 Converter
Two encoders on one page: URL percent-encoding (with a choice between encoding a value and encoding a whole URL) and Base64. Both directions, live as you type, and safe for any language or emoji — where many tools silently corrupt non-ASCII text.
Result
The encoded result appears here as you type.
Back to building in Moda
Encoded string sorted — return to the design or page you needed it for.
Try Moda free →Component vs. whole-URL encoding
The tool’s two URL modes match JavaScript’s two functions. Component mode (encodeURIComponent) encodes every reserved character — right when the text is a value going inside a URL, like a query parameter, where a literal & or = would split the parameter in two. Whole-URL mode (encodeURI) leaves the characters that give a URL its structure (:, /, ?, #, &) untouched — right when you have a complete URL with spaces or non-ASCII characters and just need it made valid. Component mode is the default because values are the common case; run a full URL through component mode and its slashes become %2F, which is usually not what you meant.
Base64 is encoding, not encryption
Base64 re-writes bytes into 64 safe characters so binary or arbitrary text can travel through systems that only handle plain ASCII — data URLs, basic auth headers, JSON payloads, email attachments. Anyone can decode it instantly; it hides nothing and never substitutes for encryption. The output is about a third longer than the input, which is the tax for the safety.
Why Unicode breaks naive Base64 tools
The browser’s built-in btoa() only accepts characters up to code point 255, so “café”, Cyrillic, Chinese, or any emoji makes it throw — and tools that work around it carelessly produce Base64 that decodes to garbage elsewhere. This page converts text to UTF-8 bytes first and encodes those, the same convention virtually every decoder expects, so 🎉 encodes to 8J+OiQ== and comes back as 🎉 anywhere.
Decoding errors, explained instead of mangled
Decode input that isn’t valid gets a specific inline message, not silent wrong output: percent sequences that are cut off or malformed, Base64 with characters outside the alphabet or broken padding, and — the subtle one — valid Base64 whose bytes aren’t text at all but binary data like an image. Whitespace and line breaks inside pasted Base64 are tolerated, since encoded blobs often arrive wrapped from email or terminal output.
Frequently asked questions
When do I need URL encoding?
Whenever text you don’t control goes into a URL: search terms into a query parameter, a redirect target into ?next=, a title into a share link. Unencoded, characters like &, ?, #, and spaces change the URL’s meaning or break it entirely. Encode the value (component mode), then place it in the URL.
What’s the difference between %20 and + for spaces?
Both appear in the wild: %20 is standard percent-encoding, while + means a space only in one specific context — form-style query strings. This tool emits %20, which is correct everywhere. When decoding, a + is left as a literal plus, because outside form data that’s what it is.
Is Base64 secure for passwords or secrets?
No. Base64 is reversible by anyone in milliseconds — it’s a transport format, not protection. If you’ve seen credentials Base64-encoded (basic auth headers, config files), the encoding is there for character safety, and the security must come from the channel, like HTTPS.
Why does my Base64 from another tool fail to decode here?
Two common causes. URL-safe Base64 replaces + and / with - and _ (used in JWTs, for instance) — swap them back and it decodes. Or the data decodes fine as bytes but isn’t text — a Base64-embedded image, say — which this tool reports rather than printing binary garbage.
Is my text sent to a server?
No — both encoders run entirely in your browser as you type. Nothing you paste here is uploaded, logged, or stored, which matters when the text is a token, URL, or config snippet from work.