Overview
Four live converters in one panel: Base64 encode, Base64 decode, URL percent-encode and URL percent-decode. Base64 output uses the standard alphabet with = padding, URL mode uses encodeURIComponent semantics, and both directions handle full UTF-8 including emoji. A swap button feeds the output back in as input, and character and byte counters sit under both panels.
How It Works
Click one of the four mode tabs at the top. Type in the left panel and the right panel updates on every keystroke. Use the Swap button to reverse direction: it moves the current output into the input and switches to the opposite mode, so an encoded string can be round-tripped in two clicks. Decode errors, such as malformed Base64 or a stray percent sign that is not part of an escape, are shown as an error message in the output panel and the copy button disables until the input is valid.
Step-by-Step Usage Guide
- Pick a mode tab: Base64 encode, Base64 decode, URL encode, or URL decode.
- Type or paste into the input panel; conversion is immediate.
- Press Swap to use the output as the new input with the opposite mode.
- Copy the result with the output panel's copy button, checking the byte counter if size matters.
Technical Specifications & Standards
The UTF-8 handling uses the classic escape trick: encodeURIComponent-then-unescape converts the text to a binary string that btoa can accept, and the mirror image (atob, then escape-then-decodeURIComponent) reverses it, which is why a rocket emoji encodes cleanly where a plain btoa call would throw a Latin-1 range error. URL mode delegates to encodeURIComponent, which escapes everything outside the unreserved set plus a handful of reserved characters; note that it encodes spaces as %20, not as +, which is the form-urlencoded convention and the usual culprit when a decoder shows %20 where you expected a plus. The Base64 produced here is the standard RFC 4648 alphabet: it contains + and / and is not URL-safe, so if you need Base64url (minus and underscore), you must replace those two characters yourself after copying. Decoding is strict in the useful sense: atob throws on strings whose length is not a multiple of four or that contain foreign characters, and that exception is surfaced as a readable error rather than being swallowed.
Targeted Use Cases
- Encoding an Authorization header payload or a JWT segment for a quick API test.
- Building a data URI query parameter with reserved characters safely escaped.
- Decoding a Base64 blob from a log line or an email header back into readable text.
- Verifying that emoji and CJK text survive an encode-decode round trip in a client.
Notes & Gotchas
- Use URL encode, not Base64, when the value goes into a query string; Base64's + and / will be mangled by servers expecting percent-encoding.
- Remember spaces encode as %20 here, not +; if your backend expects +, convert explicitly.
- Trim whitespace from Base64 before decoding; line breaks inside the string cause a decode error.
- Treat the swap button as your round-trip test: encode, swap, decode, and confirm you got the original back.
Frequently Asked Questions
Is the Base64 output URL-safe?
No. The output uses the standard RFC 4648 alphabet including + and / with = padding. For Base64url, replace + with -, / with _, and usually drop the padding before using it in a URL.
Why does an emoji encode correctly here but break in my own btoa call?
btoa only accepts characters in the Latin-1 range. This tool first converts UTF-8 text into binary-safe form before calling btoa, which is the standard workaround for non-ASCII input.
Should spaces become %20 or +?
In this tool they become %20, following encodeURIComponent. The + convention belongs to the application/x-www-form-urlencoded format used by HTML form submissions, and mixing the two is a common decode bug.
What happens if I decode invalid input?
The output panel shows the error the decoder threw, such as a malformed percent escape or a bad Base64 character, and the copy button is disabled so a broken result is not copied by accident.