Developer Tools
JSON formatter, slug generator, SHA hashes and a color converter for developers.
These are the small, constant tasks of building software: making sense of a minified JSON response, checking what is inside a token before deciding why authentication is failing, working out which timestamp a log line refers to, seeing exactly what changed between two versions of a file. Individually trivial, collectively a large share of the day — and each one runs here in the browser rather than pasting production data into somebody's server.
Which tool do you need?
- JSON Formatter
- An API returned a single unreadable line and you need it indented, or you need to know why it will not parse.
- JWT Decoder
- You are debugging authentication and need to see the claims and expiry inside a token.
- Unix Timestamp Converter
- A log or a database field holds an epoch number and you need the actual date and time.
- Text Diff Checker
- Two versions of a config, a query or a document differ somewhere and you need to see exactly where.
- Regex Tester
- You are writing a pattern and want to see what it matches before shipping it.
- Hash Generator (SHA)
- You need a SHA digest — verifying a download, comparing files, generating a deterministic key.
- UUID Generator
- You need unique identifiers for test data, seeds or fixtures.
- Slug Generator
- A title has to become a clean URL segment — lowercase, hyphenated, no accents.
- Color Converter
- You have a colour in HEX and need RGB or HSL, or the other way round.
- CSV to JSON
- A spreadsheet export has to feed something that expects structured JSON.
- JSON to CSV
- An API response needs to go into a spreadsheet for someone who does not read JSON.
- Number Base Converter
- You are moving between binary, octal, decimal and hexadecimal — permissions, masks, colour values.
- URL Parser
- A long URL needs breaking into its host, path, query parameters and fragment.
A JWT is signed, not encrypted — and that changes how you treat it
A JSON Web Token is three Base64url-encoded parts separated by dots: a header, a payload of claims, and a signature. The first two are merely encoded, which means anyone holding the token can read every claim inside it without any key at all — that is what a decoder does, and why it works instantly and offline. The signature does not hide the contents; it proves they have not been altered, and verifying it requires the secret or public key. Two practical consequences follow. First, never put anything confidential in a JWT payload, because it is effectively public to whoever holds the token. Second, a decoder can tell you what a token claims and when it expires, but it cannot tell you whether the token is valid — only your server can.
Why timestamps are so reliably confusing
A Unix timestamp counts seconds since 1 January 1970 UTC, which makes it unambiguous and completely unreadable. Most of the confusion comes from three places. Some systems store seconds and others milliseconds, so a number that decodes to 1970 usually means you have milliseconds being read as seconds, or the reverse gives you a date far in the future. Timestamps are always UTC, so a log entry can look an hour or more off simply because you are reading it in local time — and daylight saving makes that offset change during the year. And a value stored as a 32-bit signed integer runs out in January 2038, which is a real constraint in older systems rather than a curiosity.
What makes JSON fail to parse
The same handful of mistakes account for almost every parse error. A trailing comma after the last element, which JavaScript tolerates in source code and JSON does not. Single quotes instead of double quotes — JSON requires double, always, for both keys and strings. Unquoted keys, which are fine in a JavaScript object literal and invalid in JSON. Comments, which JSON has no concept of. And smart quotes substituted by a word processor, which look almost identical to straight quotes and are the hardest of the set to spot by eye. A formatter helps mainly by showing where the parser gave up, which is usually a character or two after the actual mistake.
Why running these locally matters
The inputs to these tools are, by their nature, sensitive: production tokens, API responses containing customer records, connection strings, internal config. Pasting those into a hosted service means transmitting them to a third party and trusting a retention policy. Everything here executes in JavaScript in your own tab — no request carries your input, nothing is logged, and the tools keep working with the network off. For a JWT decoder in particular this is not a nicety, since a live token is a credential.
Frequently asked questions
Can this tool verify a JWT signature?
No. Decoding shows the header and claims, which needs no key. Verifying the signature requires the secret or public key and belongs on your server, not in a browser tab.
Are my tokens and API responses sent anywhere?
No. Everything runs locally in your browser. Nothing is transmitted, logged or stored, which is the main reason to use a local tool for this kind of data.
Why does my timestamp decode to 1970?
You are almost certainly passing milliseconds where seconds are expected. Divide by 1000. The reverse mistake produces a date thousands of years in the future.
Which hash should I use?
SHA-256 for integrity checks and general use. MD5 and SHA-1 are broken for security purposes and should only be used against legacy checksums. For password storage, none of these are appropriate — that needs a purpose-built algorithm like bcrypt or Argon2 on a server.