Most of my debugging time isn't spent on hard problems. It's spent on small chores: reading a minified API response, checking what's inside a token, converting a timestamp. Here are five of them, what's actually going on in each, and the quickest way to handle them.
1. Reading minified JSON
An API returns one 4,000-character line and you need to find one field. Pretty-printing it makes the structure obvious, and validating it tells you where a malformed payload breaks.
Common causes of "Unexpected token" errors:
- A trailing comma after the last item
- Single quotes instead of double quotes
- Unquoted keys
- An HTML error page returned where you expected JSON (the error usually points at the first
<)
A formatter shows the exact line and character of the error. I use this JSON formatter and validator for quick checks.
2. CSV to JSON (and back)
You get a spreadsheet export and need JSON for a test fixture, or the reverse. The catch is quoting. A field like "Smith, John" contains a comma, so a naive split(",") breaks it.
// Fragile: breaks on quoted commas
const rows = csv.split("\n").map(line => line.split(","));
For one-off conversions, a converter saves the trouble. CSV to JSON and JSON to CSV cover both directions. For anything in production code, use a real parser such as Papa Parse.
3. Looking inside a JWT
A JWT is three Base64URL-encoded parts separated by dots: header.payload.signature. The header and payload are just JSON, so you can read them without any key:
const [header, payload] = token.split(".");
const decode = s => JSON.parse(atob(s.replace(/-/g, "+").replace(/_/g, "/")));
console.log(decode(payload));
// { sub: "123", exp: 1767225600, ... }
Two things to remember:
- Decoding is not verifying. Anyone can read a JWT's contents. Only checking the signature with the right key tells you it's genuine.
- Don't paste live production tokens into random websites. Use expired or test tokens, or decode locally.
When I just want to check exp or aud on a test token, a JWT decoder is faster than writing the snippet.
4. Unix timestamps
1767225600 means nothing to a human. Two things trip people up:
-
Seconds vs. milliseconds. Ten digits is seconds, thirteen digits is milliseconds. Passing seconds to JavaScript's
new Date()gives you a date in January 1970. - Time zones. Timestamps are UTC. The conversion to local time is where bugs appear.
new Date(1767225600 * 1000).toISOString();
A timestamp converter is handy for checking logs.
5. Testing a regex before it ships
Write the pattern against real sample input before putting it in code. Test the cases that usually break it:
- Empty strings
- Extra whitespace
- Multi-line input
- Unicode characters
Watch for greedy matching (.* grabs more than you expect) and for patterns with nested quantifiers like (a+)+, which can cause catastrophic backtracking on bad input. A regex tester lets you iterate quickly.
Bonus: other small tools worth bookmarking
- Base64 encoder/decoder for inspecting encoded payloads and data URIs
- Text diff checker for comparing two config files or API responses
- UUID generator for test data
Wrapping up
None of these tasks is hard. The time goes to context-switching and rewriting the same throwaway snippets. Bookmark a few tools, learn what each format is really doing, and save your focus for the real bugs.
All the tools linked above are free and need no signup. They're part of Erapse, a site I run with free calculators and web tools. What small chores would you add to this list?
Top comments (0)