Base64 Encoder / Decoder

Computers speak in bytes, but many systems only understand plain text. Email protocols, HTML documents, and JSON APIs choke on raw binary data — a stray null byte or control character can break everything. Base64 solves this by translating any sequence of bytes into a safe alphabet of 64 characters: A-Z, a-z, 0-9, plus, and slash. The result is always printable, always safe to paste into a text field.

URL encoding tackles a different problem. Web addresses reserve certain characters for special purposes — the question mark starts query parameters, ampersands separate them, spaces aren't allowed at all. When your data contains these characters, URL encoding replaces them with percent signs followed by hex codes. A space becomes %20, an ampersand becomes %26. Both encodings are reversible, meaning you can always get your original data back.

This tool handles both transformations in real time. Paste your input, pick your direction, and the encoded or decoded result appears instantly. UTF-8 characters work correctly, so emoji, accented letters, and Asian scripts encode without corruption.

Base64 works by grouping your input into chunks of three bytes — that's 24 bits total. It then splits those 24 bits into four groups of 6 bits each. Since 6 bits can represent values from 0 to 63, each group maps to one of the 64 safe characters. The encoding always produces output 33% larger than the input.

Take the word "Hi" as a concrete example. The letter H is byte value 72, and i is 105. In binary, that's 01001000 01101001 — sixteen bits total. Base64 pads this to 24 bits by adding eight zeros, giving three 6-bit groups: 010010, 000110, 100100. These map to characters S, G, and k. The padding gets marked with an equals sign, so "Hi" becomes "SGk=".

URL encoding is simpler arithmetic. Each unsafe character gets replaced by a percent sign plus its two-digit hexadecimal value. The space character is decimal 32, which is hex 20, so spaces become %20. A plus sign (decimal 43, hex 2B) becomes %2B. Reserved characters like slashes and colons also get escaped when they appear in data rather than as URL structure.

Suppose you're building a single HTML file that needs to display a small logo without linking to an external image. Your logo.png is 847 bytes. You open the file in this tool's Base64 encoder and get a string of 1,132 characters. You then construct a data URI by prepending the MIME type: data:image/png;base64, followed by that encoded string. Paste the whole thing into an img tag's src attribute.

The browser reads the data URI, decodes the Base64 back into raw PNG bytes, and renders the image — no server request needed. This technique works beautifully for small icons under 5KB. For larger images, the 33% size increase becomes wasteful, and caching benefits disappear. Your HTML file becomes self-contained though, which matters for email signatures, offline documentation, or downloadable single-page tools.

You can reverse this process too. If someone sends you a data URI and you want to inspect the original file, paste everything after the comma into the decoder. The raw bytes decode, and you can analyze what's actually inside.

JSON Web Tokens look intimidating — long strings separated by two dots — but they're just three Base64-encoded segments. The first segment contains header metadata, the second holds the actual payload with user data and permissions, and the third is a signature. When authentication fails and you're staring at a JWT, paste that middle segment into the decoder. You'll see plain JSON revealing the user ID, expiration timestamp, and whatever claims the server included.

HTTP Basic Authentication uses Base64 in a simpler way. The username and password get joined with a colon — like admin:secretpass123 — and the whole thing gets encoded. The result rides along in the Authorization header. If you're debugging API calls and need to verify credentials are formatted correctly, encode your credentials here and compare against what your application sends.

URL encoding becomes essential when building API requests with special characters. Searching for "rock & roll" in a query parameter? Without encoding, that ampersand looks like a parameter separator. Encode it to rock%20%26%20roll, and the server receives your actual search term intact.

The most common mistake is encoding text that's already encoded. If someone hands you a Base64 string and you encode it again, you've created a double-encoded mess. The decoder will return another Base64 string instead of readable text. When output looks like random characters but almost decodes, check whether your input was already transformed. The Swap button helps here — decode, examine the result, then decide if another round is needed.

Character encoding mismatches cause subtle corruption. If your source text uses Windows-1252 encoding but the decoder assumes UTF-8, accented characters turn into garbage. This tool expects UTF-8, which handles virtually every modern text correctly. Legacy systems sometimes produce Latin-1 or other encodings though. When decoded text shows strange characters where accents should be, the problem usually traces back to the original encoding step using the wrong character set.

Padding errors trip people up with Base64. Valid Base64 lengths are always divisible by 4, with equals signs filling any gap. If someone accidentally truncated a string, you'll get decoding errors or corrupted output. Count the characters — a string of 143 characters can't be valid Base64. Either something got cut off, or the data was never Base64 to begin with.