Encoding Tools

Data rarely travels in the form it started in. Binary files are turned into text so they survive email and JSON, and text is escaped so it can sit safely inside a URL. When one side encodes and the other decodes differently, you get broken links, mangled accents or tokens that no longer validate. This category gathers free converters that show exactly what changed and why, running entirely in your browser so nothing you paste is uploaded.

Base64 encoder and decoder

The Base64 encoder and decoder converts text to Base64 and back, with the standard and URL-safe alphabets, optional line wrapping for MIME and PEM, and correct UTF-8 handling so accents and emoji survive a round trip. It reports the size overhead and falls back to a hex view when the decoded bytes are not text, which makes it ideal for inspecting data URIs, Basic authentication headers and the parts of a JWT.

URL encoder and decoder

The URL encoder and decoder percent-encodes a single value or a complete address, decodes %XX sequences back to readable text and breaks a link into its host, path and query parameters. It spots malformed escapes and double encoding, such as a space that has turned into %2520, and offers form-style plus signs for spaces when you need them.

When to use them

Use them when a link with a search term or redirect breaks, when an API receives parameters that look corrupted, when you need to read a token or a certificate by hand, or when you are embedding a small image as a data URI. Seeing the exact bytes on both sides usually reveals the mismatch in seconds.

Encoding is not security

Base64 and percent-encoding make data safe to transport, not safe from being read. Anyone can reverse them, so never rely on either to hide a password, a token or personal data. When you need secrecy, use real encryption or a signed token, and keep secrets out of URLs, which end up in logs and browser history.

Common encoding mistakes

Most bugs come from a few repeat offenders: decoding base64url with the standard alphabet, dropping the = padding that a strict decoder expects, encoding a value twice so a space becomes %2520, using encodeURI where encodeURIComponent was needed, or reading UTF-8 bytes as Latin-1 so accents turn into é. Comparing input and output side by side shows which one you are dealing with.

Quick encoding checklist

Know which format the other side expects before you encode: standard or URL-safe Base64, padded or not, a single value or a whole URL, spaces as %20 or +. Encode exactly once, at the moment the value is placed into the URL or payload, always use UTF-8, and decode a sample to confirm the round trip returns the original. Keep a few known-good samples at hand, so you can test a library or framework upgrade against them in seconds.

Learn the details

Both converters link to in-depth guides that explain how the encodings work, the padding and alphabet differences that trip people up, and how to troubleshoot output that will not decode.

Tip: encode a value once, at the point where it enters a URL, a header or a data URI, and decode it once where it leaves. Encoding twice is the most common cause of %2520 and garbled Base64. A quick check is to decode the value once and see whether it still contains % or = characters that should not be there. Keep a copy of the result so you can compare it after the next change.