Developer Tools
A set of everyday developer utilities — converting colors, generating cryptographic hashes, working with Unix timestamps, and decoding JWTs.
Quick tasks
One click opens the tool already set up for the job.
Developer Tools - Colours, Hashes, Timestamps and JWTs
This is the category for the small conversions that interrupt real work. A design hands you a HEX colour and CSS wants HSL. A log line has a Unix timestamp and you need to know what time that was in your own timezone. An API returns a token and you need to see what is inside it. A download page lists a SHA-256 and you have to check the file. None of these is hard; all of them are annoying to do by hand, and all four run here without an account.
What is in this category
| Tool | What it does | Reach for it when |
|---|---|---|
| Color Converter | Converts between HEX, RGB and HSL | A palette is in one notation and your stylesheet wants another |
| Hash Generator | Computes MD5, SHA-1, SHA-256 and SHA-512 for text or a file | Verifying a download, comparing two files, or generating a cache key |
| Timestamp Converter | Converts Unix timestamps to readable dates and back, across timezones | A log, a database column or an API response contains a number where a date should be |
| JWT Decoder | Splits a JSON Web Token and shows its header, payload and expiry | Debugging authentication and needing to see the claims |
| Unused CSS Remover | Keeps only the CSS a page uses, from a Chrome Coverage export or from the HTML | A theme or page builder loads far more CSS than the page needs |
| Code Formatter | Beautifies or minifies HTML, CSS, JavaScript and SQL, with SQL dialects and the language detected for you | A bundle, a template or a query arrived as one unreadable line, or a snippet has to be as small as possible |
| Cron Expression Explainer | Reads a cron schedule in plain language, field by field, with its next run times in local time or UTC | A job runs at the wrong hour, or you need to be sure what a crontab line does before deploying it |
| Subnet Calculator | Network, broadcast, host range, masks and address type for IPv4 and IPv6, and splits a network into subnets | Writing a firewall rule, a VPC plan or a router config, and the range has to be exactly right |
| User-Agent Parser | Reads the browser, engine, OS and device in any user-agent string, and names search engine and AI crawlers | A log line, an analytics report or a bug report shows a user agent you need to understand |
| JSON to Types | Turns a JSON sample into TypeScript, Go, Python, C# or Rust types, or a JSON Schema | An API returns JSON and your code needs typed models for it |
Colour notations and why HSL is worth knowing
HEX and RGB describe exactly the same thing in different handwriting: #4F46E5 is rgb(79, 70, 229), three channels of 0-255 written in hexadecimal instead of decimal. Converting between them is mechanical.
HSL is a genuinely different model, and that is why it earns its place. It describes a colour as hue (position on the colour wheel, 0-360), saturation (how vivid, 0-100%) and lightness (0-100%). The practical payoff: making a colour 10% darker for a hover state is a single change to one number, and building a palette of related shades means holding hue and saturation still while walking lightness. Doing the same in HEX means recalculating three channels and guessing.
Contrast is the other reason to care. Text needs a contrast ratio of at least 4.5:1 against its background to meet WCAG AA at normal sizes. Lightness in HSL is a much better predictor of where you stand than staring at a hex code.
Hashes: what they are for, and what they are not
A hash function turns any input into a fixed-length fingerprint. The same input always gives the same output; a one-character change gives a completely different one; and you cannot work backwards from the hash to the input. That makes hashes the right tool for verifying integrity and the wrong tool for storing passwords.
| Algorithm | Output | Status |
|---|---|---|
| MD5 | 128 bits | Broken for security. Collisions can be produced deliberately. Fine as a non-security checksum or cache key |
| SHA-1 | 160 bits | Broken since 2017. Still seen in older systems and in Git object IDs; do not choose it for anything new |
| SHA-256 | 256 bits | The current default for file verification, signatures and certificates |
| SHA-512 | 512 bits | Same family, larger digest, often faster on 64-bit hardware |
The everyday use is verifying a download: the site publishes a SHA-256, you hash the file you received with the hash generator, and the two strings either match character for character or they do not. It catches a truncated download and a tampered mirror alike.
The thing hashes are not for is passwords. A plain SHA-256 of a password can be attacked at billions of guesses per second on ordinary hardware. Password storage needs a slow, salted, purpose-built function - bcrypt, scrypt or Argon2 - designed to be expensive on purpose. If you are hashing a password with anything in the table above, that is a bug. The hash generator has a bcrypt tab for exactly this: it makes a bcrypt hash with the cost you choose and checks a password against a stored one, and the bcrypt page opens it directly.
Unix timestamps and the timezone confusion
A Unix timestamp counts seconds since midnight UTC on 1 January 1970. It has no timezone, which is precisely why systems use it: it is one unambiguous instant, and every language can turn it into local time for display. A ten-digit number is seconds; a thirteen-digit one is milliseconds, which is what JavaScript's Date.now() returns and a very common source of dates landing in 1970 or in the year 55000.
The timestamp converter goes both ways and shows the result in UTC alongside your local time, which is usually the comparison you actually need when reading a log written on a server in another region. Two dates worth knowing: 2147483647 is the last second a signed 32-bit timestamp can hold, in January 2038, and 0 is the epoch itself - a timestamp of 0 or a date of 1 January 1970 almost always means a value was never set rather than genuinely being that old.
Reading a JWT
A JSON Web Token is three URL-safe Base64 segments separated by dots: a header saying which algorithm signed it, a payload of claims, and a signature. The JWT decoder splits it and shows the first two as readable JSON, with exp and iat rendered as dates - which is normally the whole question when a request is being rejected.
Two things to be clear about. First, the payload is not encrypted. Anyone holding the token can read every claim in it, so a JWT is not a place to put anything private. Second, decoding is not verifying: reading the claims tells you what the token says, not whether the signature is valid. Only the server holding the key can answer that, and no browser tool should ask you to paste your signing secret to find out.
Because a token is a live credential for as long as it is valid, where you paste it matters. This decoder runs entirely in your browser - the token is parsed by JavaScript on your machine and never sent anywhere, which you can confirm in the network panel.
Related categories
- Encoding tools - a JWT is URL-safe Base64 underneath, and knowing that explains most decoding failures.
- Generator tools - generate the identifiers and secrets that these tools later inspect.
- Text tools - format the JSON that comes out of a decoded payload.
- Image tools - convert assets while you are working through the same design task.