Small Developer Tools That Quietly Save Hours Every Week

Most of the time a developer loses in a day is not lost to hard problems. It goes to small friction — pretty-printing a response to read it, decoding a token to check one claim, sanity-checking a regex, working out whether a timestamp is seconds or milliseconds. Each one is thirty seconds of yak-shaving, and there are forty of them.

The fix is not a bigger IDE. It is a handful of single-purpose tools you can reach in one keystroke, so the friction task takes five seconds instead of two minutes. Here is the set I actually use, grouped by the work they support, with the honest note on when not to reach for each.

Working with JSON#

A JSON viewer and formatter#

The problem: an API returns a 4 KB blob on one line and you need to find one field three levels deep.

When you need it: debugging an unfamiliar API, inspecting a webhook payload, reading a config dump, checking what your own endpoint actually returns.

How it fits: paste, format, collapse the branches you do not care about, find the field. A good one — like Useful Hacks' JSON Viewer & Formatter — also validates as it formats and can convert to YAML or CSV, all in the browser with nothing uploaded.

Common mistake: using it as your only check. Formatting proves the JSON parses, not that it is correct. If you are comparing "what I sent" against "what they received", use a structural diff instead of eyeballing two formatted blobs.

When not to use it: anything with secrets or personal data in it. For a production payload, format it locally (jq, your editor) rather than pasting it into a website.

A validator, a diff, and a type generator#

Three close cousins worth knowing:

• Validator — when a parser fails with Unexpected token } in JSON at position 812, a validator that reports the line and column is faster than counting characters.
• Diff — comparing two API responses, or a fixture against live output, is a job for a structural JSON diff that ignores key order, not git diff on formatted text.
• JSON → types — starting to type a previously untyped API? Generate TypeScript interfaces from a sample and refine from there. Treat the output as a draft — a single sample will miss optional and nullable fields.

Tokens, encoding, and auth#

A JWT decoder#

The problem: a request is 401 and you need to know whether the token is expired, has the wrong audience, or is missing a scope.

When you need it: debugging auth, reading a token from a log line, checking what your identity provider actually put in the claims.

How it fits: paste the token into a JWT decoder, read the header and payload, check exp, aud, iss, scope.

Common mistake: thinking the decoder verified the token. It did not — it base64-decoded it. Signature verification happens server-side with the key.

When not to use it: on a real user's production token. A JWT is a bearer credential; a valid one pasted into a browser tab is a credential you have now handled carelessly. Use a throwaway token from a test account.

Base64 encode / decode#

Small but constant: inspecting a data: URI, decoding a base64 field in a payload, encoding a small asset for a config file. A base64 tool does it without a scratch script. Same caveat — not for secrets.

Text and patterns#

A regex tester with live highlighting#

The problem: you have a regex that works on three examples and you are about to ship it against millions of strings.

When you need it: writing any non-trivial pattern — log parsing, input validation, a find-and-replace across a codebase.

How it fits: a regex tester with live match highlighting and a capture-group breakdown lets you paste real sample data and see what matches before it runs in production.

Common mistake: testing only the happy path. Paste in the empty string, a string with newlines, unicode, and the input that is one character off. Watch for catastrophic backtracking on adversarial input.

When not to use it: as a substitute for a real parser. If you are matching nested structures or HTML, a regex is the wrong tool no matter how well it tests.

A Markdown formatter#

Docs, PR descriptions, and READMEs drift into inconsistent spacing and broken list nesting fast — especially when several people (or an AI draft) have touched them. A Markdown formatter normalises it in one pass so the rendered output is predictable.

Time and HTTP#

A timestamp converter#

1735689600 — is that seconds or milliseconds, and what date is it? A Unix timestamp converter answers both directions instantly, with timezone handling. You will use it every time you debug anything involving createdAt, token expiry, or a cron schedule.

An HTTP status code reference#

Not because you forget what 404 means — because you are choosing between 400, 409, 422 and 429 for an error case and want the semantics right. A status code lookup is a two-second check that keeps your API honest.

A note on AI-assisted work#

AI tools have not made these utilities redundant — if anything they generate more code and sample data that needs a quick deterministic check. Where AI does fit is the reasoning around a task, and the same "keep the ones that work" principle applies to prompts. A structured prompt builder enforces the role / task / constraints / output shape, a prompt library is the prompt equivalent of a snippets folder, and a prompt optimizer scores a draft when it is close but not landing. I go deeper on that side of the workflow in AI in the Developer Workflow.

Useful resources#

• Developer utilities — every tool above is in the Useful Hacks developer tools index; the JSON Viewer & Formatter and Regex Tester are the ones I open most.
• For the AI-assisted parts — Prompt Studio and the Prompt Library.

The pattern underneath#

Keeping these one keystroke away is the whole trick. It removes the tax on the small stuff so attention stays on the part that actually needs it — the design, the edge cases, the thing that is genuinely hard.

Building focused single-purpose tools is something I enjoy — I designed and shipped a web tools product end to end on my own, and it shaped how I think about frontend engineering. If you are working on something in this space, or have a technical problem worth talking through, get in touch.