Encoding, hashing and encryption are three different things
Almost every misunderstanding on this page comes from treating these as interchangeable, so they are worth separating properly.
Encoding is reversible and has no secret in it. Base64 exists to carry binary data through channels that only accept text — email attachments, data URIs, JSON strings — by representing every three bytes as four characters, which is why the result is always about a third larger. There is no key. Anyone who sees the string can decode it in one step, including on this site. Base64 is not security, not obfuscation worth the name, and not a way to hide anything from anyone who looks. Percent-encoding is the same kind of thing for URLs, and it is where the other common bug lives: encoding one value that goes into a query string is a different operation from cleaning up a whole assembled URL, because only the first escapes the &, =, ? and / that give a URL its structure. Get it wrong and "Smith & Sons" arrives at the server as two parameters instead of one value.
Hashing is one-way and has no key either. A hash takes any input and produces a fixed-length fingerprint, and there is no undo — not because it is encrypted but because the information is gone. What you can do is guess inputs and compare, and that is exactly what makes MD5, SHA-1 and SHA-256 wrong for storing passwords: they are fast, a graphics card computes billions of them a second, and a stolen table of them is cracked at that speed. Passwords need a deliberately slow, salted function — bcrypt, scrypt or Argon2. Separately, MD5 and SHA-1 are broken for a different reason: two different files with the same hash can now be constructed deliberately, so neither can prove a file is the file you expected, though both remain fine for spotting an accidentally corrupted download.
Encryption is the one with a key, and none of these tools do it. That is not an omission. Doing encryption properly requires key management, and a web page is the wrong place for a key.
A JWT is signed, not encrypted, and this catches people out constantly. The header and payload of a token are Base64URL — readable by anyone who holds the token, no key required. The signature stops someone changing the token; it does nothing to stop them reading it, so nothing confidential belongs in a payload. It follows that decoding a token proves absolutely nothing about it: anyone can write any claims they like and Base64 them. Verifying means recomputing the signature with the issuer's key, which is a thing your server does and a website must never ask for. Our decoder therefore refuses to imply verification, and flags the shapes that indicate a problem — an expired token, a token with no expiry at all, and an algorithm of "none", which is a documented authentication bypass rather than a curiosity.
JSON has a number precision limit that most formatters silently walk into. JSON itself puts no bound on the size of a number, but a JavaScript number is a 64-bit float, so whole numbers stay exact only up to 9,007,199,254,740,991. A Twitter post ID, a Discord snowflake, a 64-bit database key or a bank account number is larger than that, and passing it through the usual one-line formatter — parse, then stringify — changes its last digits. The result still looks like a plausible number, which is what makes it dangerous: 7205759403792793600 quietly becomes 7205759403792793000. Our JSON tools re-serialise the exact digits you pasted and tell you how many numbers they had to protect.
A UUID version describes how it was made, not what it guarantees. Nothing registers a UUID or enforces uniqueness; uniqueness is probabilistic, and the version tells you where the bits came from. Version 4 is 122 bits of randomness from the browser's cryptographic generator, which makes it unguessable and therefore right for reset links, invite codes and anything secret — and wrong as a database key, because random keys scatter through a sorted index and fragment it. Version 7 puts a 48-bit millisecond timestamp first, so keys append to the end of the index like an auto-incrementing integer while staying globally unique. The trade is that a v7 UUID plainly reveals when it was created, to the millisecond, to anyone who has it.
Where a browser is genuinely the wrong tool
All thirteen of these run on your device. No request is made, nothing is logged, and the pages keep working with the network disconnected — which is precisely why they are usable on an API response full of customer records or a token you would not email to anyone. That is the honest case for them. Here is the honest case against.
Pasting a live production secret into a web page is a habit worth not having — including this one. Our privacy claim is true, but a claim is not what protects you; the behaviour of the code is, and the only sensible posture towards any web page is to check rather than trust. The check costs nothing: open your browser's developer tools on the Network tab before you paste, or disconnect from the internet after the page has loaded and watch these tools carry on working. A tool that needed a server would stop. And if a credential is still valid and you have already pasted it somewhere you cannot audit, the right move is to rotate it, not to reason about it. For a token that is live right now, decoding it locally — your language's own Base64 function, or two lines in a shell — is better practice than any website, ours included.
Schema validation. Our JSON and XML tools check that a document is well-formed, which is a different question from whether it matches a schema. Validating against JSON Schema or an XSD means fetching and applying a schema file, which is a network request these pages deliberately never make. Use ajv for JSON Schema and xmllint for XSD and DTD; both are free and both are better at it than a web page could be.
Anything genuinely large, or streamed. Documents are held in memory whole, sometimes twice while formatting, so the ceiling is the tab. A few megabytes is instant and a few hundred is not. jq streams a multi-gigabyte JSON file that no browser will open, and ripgrep searches a whole repository faster than you can paste one file. Hashing has a sharper version of the same limit: the browser's cryptography has no incremental digest, so the whole file must fit in memory at once — a DVD image will fail, where sha256sum, shasum or certutil stream it without noticing.
Automation and CI. These run when a person clicks. Formatting every file in a repository, generating ten thousand UUIDs into a fixture, or checking JSON in a pipeline belongs in a script: jq, xmllint, uuidgen, openssl and the base64 command are installed on most machines already.
Verifying anything signed. Signature verification, certificate chains and anything requiring a private key should happen on your server with a library that is maintained. This page will tell you what a token claims; it will never tell you that a token is genuine, and you should distrust any site that says it can without your key.
Choosing between the tools that sound alike
JSON Formatter vs JSON Validator. Same parser, different question. The formatter is for reading and reshaping a document that already parses — indent it, minify it, keep the big numbers intact. The validator is for a document that does not parse, and its output is the line, the column, the offending character with a caret under it, and which of the four usual causes it was. If you are staring at "Unexpected token", you want the validator. The same split holds for XML Formatter and XML Validator.
Base64 Decode vs JWT Decoder. A JWT is three Base64URL sections, so the general decoder will show you the pieces. The JWT page splits them for you, formats the JSON, turns the expiry, issued-at and not-before claims from Unix timestamps into real dates in your timezone, labels the registered claims, and warns about expiry and an algorithm of "none". Use the general decoder for a Base64 blob and the JWT page for a token.
Base64 Encode vs URL Encode. Different jobs that both produce "safe" text. Base64 turns arbitrary bytes into text at a 33 per cent size cost, and standard Base64 is not safe in a URL at all — its +, / and = all mean something there, which is why Base64URL exists. Percent-encoding leaves readable text readable and escapes only what would break the URL, which is what you want for a search term, an email address or a redirect target. Encoding a whole file for a query string is usually a sign that it should have been a request body.
Hash Generator vs UUID Generator. A hash is derived from its input, so the same input always gives the same value — that is what makes it a fingerprint, good for verifying a download or deduplicating identical content. A UUID is fresh randomness with no relationship to anything, so it never repeats. If you want the same identifier for the same content, hash it. If you want a new identifier, generate a UUID.
QR Code Generator vs Barcode Generator. QR is a two-dimensional grid that holds arbitrary text — a URL, Wi-Fi credentials, a phone number — and is read by a phone camera. The barcode page makes the one-dimensional retail and logistics codes: EAN-13, EAN-8, UPC-A, ITF-14, Code 128 and Code 39, with the retail check digit calculated and a wrong or short number refused rather than silently padded into a valid barcode for a different product.