Base64, URL, Hash & UUID Tools

Why these belong in your browser

The things people paste into an online Base64 decoder or a JWT viewer are, very often, exactly the things that should never be pasted into a website: a session token, an API response with a customer in it, a config file with a password. Every tool on this page runs inside your tab. There is no request to encode, no request to hash and no request to decode, so the data has nowhere to go. Load the page, turn off your network, and all five still work.

Base64, and the mistake that breaks non-English text

Base64 turns bytes into a safe alphabet of 64 characters, which is how binary rides inside email, JSON and data URLs. The trap is that the browser's own encoder only accepts characters up to code point 255, so passing it Tamil, Hindi, Chinese or an emoji throws an error, and the workaround most snippets suggest has been deprecated for years. This page converts your text to UTF-8 bytes first, so anything you can type encodes correctly and decodes back to exactly what you started with. The URL-safe option swaps the two characters that break inside a web address and drops the padding, which is the form used by JWTs and most APIs.

Two kinds of URL encoding

These are not interchangeable and picking the wrong one is a common bug. Use the value encoder for something going inside a parameter, where a slash or an ampersand must be escaped or it will end the value early. Use the whole-address encoder for a complete link, where the slashes and the question mark have to survive because they are structure rather than content. Decoding also treats a plus sign as a space, which is how form submissions encode them.

Hashes, and an honest warning about MD5

SHA-256 and its relatives are computed by the browser's own cryptography engine. MD5 is not offered by browsers at all, deliberately, so it is implemented on this page, and it is here for one legitimate reason: a great many file checksums, package manifests and legacy records still quote MD5, and you need to be able to check them. It must not be used for anything security related. MD5 and SHA-1 are both broken against deliberate collisions, meaning an attacker can construct two different files with the same hash, and neither is acceptable for passwords, signatures or integrity against a hostile party. For passwords specifically, no plain hash is the right answer: those need a slow, salted function such as bcrypt or Argon2 on a server.

File checksums

The file picker hashes a file from your disk without uploading it, which is the normal way to check that a download arrived intact: hash the file, compare against the string the publisher printed. A match means the bytes are identical. Note the limits of that: a matching MD5 proves the download was not corrupted in transit, but it cannot prove the file was not deliberately replaced along with the checksum on a compromised page.

JWTs are readable, not secret

The decoder splits a token and shows the header and payload as formatted JSON, with the timestamps turned into real dates, since expiry claims are in seconds rather than milliseconds and reading them wrong puts every token in 1970. It is worth understanding what this proves: the payload of a JWT is only Base64, not encryption, so anyone holding the token can read it. Signing stops it being altered, not read. There is deliberately no verify button here, because verifying needs the signing secret, and a page that asked you to paste your signing secret would be asking for the one thing you must never give a website.