Everyday developer converters in one place: format JSON, encode or decode Base64 and URLs, test regular expressions, decode JWTs, read cron expressions and diff text — all client-side.
Every conversion and check runs locally in your browser, so nothing you paste in — including tokens or personal data — is ever sent to a server.
Indentation is the side effect. The actual value is being told where the syntax broke — when an API returns "invalid JSON" and nothing else, knowing the character offset usually reveals the cause immediately.
Three causes account for most of it: a trailing comma after the last item, single quotes (JSON allows only double), and comments (JSON has none).
Sorting keys alphabetically makes two responses diffable. Identical data in a different key order otherwise shows up as entirely different.
Base64 encodes binary as text so that bytes can travel through channels that only carry text, such as email or JSON.
There is no key. Anyone can reverse it instantly. A password "hidden" in Base64 is a plaintext password.
It also grows the data by about 33% — three bytes become four characters — which matters when embedding files.
For URLs, + and / cause trouble, so the base64url variant substitutes - and _. That is what JWTs use.
encodeURIComponent escapes &, =, ? and / as well. Use it on query parameter values.
encodeURI leaves those intact. Use it on a whole URL.
Applying encodeURI to a value lets an ampersand inside it read as a parameter separator, truncating your data. Applying encodeURIComponent to a whole URL escapes :// and kills the link.
Spaces appear as %20 or + depending on context — the former in URL paths, the latter in form submissions.
A JWT is three dot-separated parts: header (algorithm), payload (claims) and signature.
The first two are plain base64url. They are not encrypted and anyone can read them — which is why secrets do not belong in a JWT payload.
Verifying the signature requires the secret or public key. This tool decodes and displays only, deliberately: asking you to paste a signing key into a web page would itself be the security problem.
The exp, iat and nbf claims are Unix seconds. Converting them to readable times usually explains a "token expired" error at a glance.
Five fields: minute, hour, day of month, month, day of week. 0 3 * * * runs daily at 03:00.
The classic trap: specifying both day-of-month and day-of-week gives OR, not AND. 0 0 1 * 1 means "the 1st of the month, and also every Monday".
*/15 means every fifteen minutes starting from zero (0, 15, 30, 45), not fifteen minutes from an arbitrary point.
Many implementations accept both 0 and 7 for Sunday. Check yours.
Confirm the timezone. On a UTC server, 0 9 * * * is not 9am where you live.
In 192.168.1.0/24, the /24 means the first 24 bits identify the network. The remaining 8 bits give 256 addresses.
254 are usable — the first is the network address and the last is broadcast.
Smaller numbers mean larger ranges: /16 is 65,536 addresses, /24 is 256, /32 is a single host. Getting that direction backwards is the most common mistake.
In firewall and security-group rules, 0.0.0.0/0 means every address on the internet. Opening SSH to it is where incidents begin.
Every conversion runs in the browser. No request is made.
That matters in real work: the JWT a developer wants to decode contains a live auth token, and the JSON they want formatted contains customer data. Pasting those into an online tool creates an exfiltration path.
This page does not create one. Open the network tab and check.
No — it decodes the header and payload so you can read them, but verifying a signature needs the secret key, which has to happen in a separate secure environment.
No. Everything is processed entirely client-side and nothing is stored or transmitted anywhere.
Yes — paste a cron expression into the cron tab to see a plain-English breakdown of when it runs.
What this tool bases its numbers on, and how far those numbers go.
JSON is parsed and re-serialised per RFC 8259. Base64 follows RFC 4648, and the URL tab uses percent-encoding per RFC 3986. JWT decoding splits the token on dots and base64url-decodes the header and payload per RFC 7519, leaving the signature untouched. Regex uses the browser's own engine, so its dialect is whatever ECMAScript provides.Base64 of the two bytes «Hi» is SGk= — two input bytes become three encoded characters plus one pad character, because Base64 packs three bytes into four.