Developer utilities without pasting secrets into a website

The small tools get the sensitive input

Nobody agonises over which website to use to convert a timestamp. It is a ten-digit number; it takes a second; you paste it into whatever the search results offered and move on.

Then consider what those ten digits usually are. They came out of a log line, during an incident, next to a user identifier. The regex you are testing is being tested against real rows, because synthetic rows do not have the problem you are debugging. The JWT you are decoding came out of a staging environment and is a live credential until it expires.

The pattern is consistent: the tools that get the least thought receive the most sensitive input, precisely because they feel too small to think about.

Where it runs is checkable

The claim “we process in your browser” is not something you have to take on faith. Open your browser’s network panel, use the tool, and watch. A page doing the work locally makes no request when you press the button. A page sending your input somewhere makes one, and you can read exactly what went.

That is worth doing once on any tool you plan to keep using, ours included. It takes fifteen seconds and it converts a marketing sentence into an observation.

The four that matter most

Decoding a JWT. A JWT is three base64url segments joined by dots: a header, a payload and a signature. Decoding the first two is base64 and JSON.parse, which is why a server is not needed and why a server-side implementation should make you ask why.

What decoding does not do is verify. The signature proves the token was issued by whoever holds the key, and checking that requires the key. A decoder shows you the claims; it cannot tell you they are true.

Testing a regular expression. The useful part is seeing what matched and where, against text that resembles what you actually have.

The dangerous part is catastrophic backtracking: nest a quantifier inside a quantifier and the engine can try exponentially many ways to fail. (a+)+$ against a string of a’s ending in b is the standard demonstration, and thirty characters is already longer than anyone will wait. There is no way to signal such a match to stop, so a tester has to be able to kill the thread doing it. Ours gives a pattern 750 milliseconds and then terminates the worker running it.

If a pattern trips that limit here, that is worth knowing before it reaches a request handler, where the same pattern is a denial-of-service bug rather than a slow page.

Converting a timestamp. Two mistakes account for almost all confusion. A ten-digit number is seconds since 1970 and a thirteen-digit one is milliseconds; reading one as the other puts you in 1970 or in the year 54,000. And a timestamp with no zone is ambiguous by exactly your offset, which is why RFC 3339 exists and why logs are worth keeping in UTC.

Checking colour contrast. WCAG asks for 4.5:1 for body text and 3:1 for large text, and the arithmetic is fixed, which is why this is the accessibility check everybody runs.

It is also the least of them. Contrast is measurable, so it gets measured; focus order, target size, motion, and whether an interface is comprehensible through a screen reader are not, and that is where the real failures are. A passing ratio means one pair of colours met one threshold, and nothing else.

Two habits that make the difference

Redact before you paste, not after. The instinct is to paste the real thing because the real thing is what is broken. Usually it is not: a regex fails on the shape of the data rather than its content, so replacing every name with the same fake name and every card number with a test number leaves the bug intact and the data gone. Where the content genuinely matters, that is exactly the case where the tool needs to be local.

Know which of your tools are already offline. Most of this exists in things already installed. date -d @1735689600 converts a timestamp, jq . formats JSON, shasum -a 256 hashes a file, and every browser’s console will decode a base64 segment in one line. A web tool is worth reaching for when it shows you something a terminal will not - a regex highlighting its matches in place, a contrast ratio next to the colours - and not merely because a search box was closer.

Hashes and formatting

Hashing answers one question: are these two files the same. Compare a download against the digest a publisher printed and either they match or something changed on the way. It is not encryption and does not conceal anything about the input.

Formatting JSON is indentation, and it earns its place by failing loudly. A parse error with a position is usually the fastest way to find the trailing comma an API response picked up.

Nothing here needs a server, so nothing here uses one

Every tool named above runs in your browser. That is not generosity - none of them needs a server, so a server-side version would be a decision to route your input through somebody else’s machine in exchange for nothing.

Check it in the network panel.