/01 The three everyday encoding jobs
Working with text on a computer produces a small set of recurring jobs. Something arrives as Base64 and needs to be read. A URL breaks because a character in it was not escaped. A file or string needs a fingerprint to prove it is what it claims to be.
This tool covers all three, in one page, with nothing leaving your machine. Base64 encode or decode a string, either direction, with the result updating as you type. URL encode or decode, for fixing and building query strings. And hashing, which produces the fixed-length fingerprints used to verify data.
Because everything runs locally, it is safe to paste values you would never send to an online converter: tokens, internal URLs, customer data from a log line. The page never makes a network request with your input, so there is nothing to sanitise before testing.
/02 Base64: an encoding, not a secret
Base64 is a way of writing binary data using only safe text characters, so it can travel through systems that only handle text: email, JSON, URLs, environment files. Every three bytes of input become four characters from a 64-character alphabet, which is why Base64 output is always a multiple of four and always longer than the input.
The essential thing to understand: Base64 is not encryption. It has no key, and anyone can reverse it instantly. It hides nothing from anyone. Its job is safe transport, not secrecy, and treating it as a way to hide data is one of the classic security mistakes.
The everyday uses are reading and writing token payloads. Many API tokens and JSON web tokens are Base64-encoded segments joined by dots. Decoding a segment lets you see what is actually in the token, which is the fastest way to debug an authentication problem, and no secrets are exposed by looking, because the signature is not in the encoded part.
When decoded text comes back as nonsense, the usual causes are input that was never Base64, a string truncated so the padding is missing, or bytes that decode to binary rather than text.
/03 URL encoding: why links break
URLs have a grammar. Certain characters mean specific things: the question mark starts the query, the ampersand separates parameters, the slash separates path segments, the hash marks the fragment. When your data contains those characters as data — a space, an ampersand inside a value, a slash in a filename — the URL parser reads them as structure, and the link breaks.
URL encoding solves it by replacing each reserved character with a percent sign and its numeric code: a space becomes %20, an ampersand %26, and so on. Encode before building, and the parser sees data where it expected data and structure where it expected structure.
The everyday cases: a search link with a user's query in it, a redirect URL that contains its own URL as a parameter, a filename with spaces in a download link, a form value that happens to contain an equals sign. Every one of these breaks unencoded and works encoded.
The decoding direction matters too. When a URL arrives with percent sequences in it, decoding shows what was actually sent, which is the first step in debugging why a parameter did not arrive as expected.
/04 Hashing: the one-way fingerprint
A hash function takes any input and produces a fixed-length output, and it works in one direction only: the same input always gives the same output, but the output cannot be turned back into the input. That makes a hash a fingerprint. Change one character of the input and the fingerprint changes completely, which is exactly what verification needs.
The tool produces MD5, SHA-1, SHA-256, and SHA-512 from the same input. The uses: checking that a downloaded file matches the hash the publisher published, proving two copies of a document are identical, comparing stored values without keeping the originals in readable form.
Worth knowing about the algorithms themselves: MD5 and SHA-1 are broken for security purposes, because collisions can be engineered, so never use them to protect anything. They remain fine for everyday integrity checks where nobody is adversarial. SHA-256 is the modern default and the right choice for anything that matters.
And the reminder that applies to all of it: a hash is not encryption either. It does not store your data in recoverable form. It confirms sameness, nothing more.
/05 Decoding Base64 you find in the wild
Base64 turns up in more places than most people expect, and a quick base64 decode often explains what you are looking at. Email source code carries attachments and non-English text as Base64 blocks. A JSON Web Token (JWT) is three Base64url sections separated by dots: the first two decode to readable JSON describing the token, while the third is a signature that decodes to binary noise. An HTTP header reading Authorization: Basic followed by a string is simply a username and password joined by a colon and Base64 encoded, which is a reminder that Basic auth is only safe over HTTPS.
Decoding here uses proper UTF-8 handling, so accented letters, non-Latin scripts and emoji come back intact instead of garbled. Because nothing is sent to a server, it is also a safe place to inspect tokens and headers from real systems, where pasting into a random online decoder would leak them.