6 debugging checks for JSON, JWT, SQL, regex, timestamps and URLs

Ali Aygör — Fri, 09 Oct 2026 22:18:31 +0000

An API failure is often easier to investigate when you separate six questions: what did the response contain, what does the token prove, which date are you reading, what does the query actually return, what does the pattern match, and what will the generated request send?

The examples below are synthetic. You can reproduce them locally without an account, a real credential or a running API.

1. Valid JSON can still have the wrong shape

The first response below is an object. The second is a JSON string containing the serialized representation of an object. Both are valid JSON.

const objectText = JSON.stringify({ ok: true });
const wrappedText = JSON.stringify(objectText);

const objectValue = JSON.parse(objectText);
const stringValue = JSON.parse(wrappedText);

console.log(typeof objectValue); // object
console.log(typeof stringValue); // string
console.log(stringValue.ok);     // undefined

Formatting checks readability; syntax validation checks whether the text parses; schema validation checks the resulting value against a contract. Those are different operations.

If your client expects an object, confirm that it is neither null nor an array. Parse a second time only if the API contract specifies an encoded string. Removing every backslash is not a reliable repair: backslashes can be legitimate string content.

2. A decoded JWT is evidence, not authentication

Reading JWT claims does not verify the signature, issuer, audience or authorization rules. Even an unexpired token can be forged, intended for another service or revoked.

JWT NumericDate values use seconds. JavaScript dates use milliseconds:

const claims = { aud: ["api", "reports"], exp: 1700000000 };
console.log(new Date(claims.exp * 1000).toISOString());
// 2023-11-14T22:13:20.000Z

The audience can also be an array. A decoder that assumes every aud value is a string can misrepresent an otherwise legitimate claim set.

Use a synthetic token for inspection. Your server must verify the token with its trusted keys and configured validation rules. A browser decoder should never label a token authentic just because its payload is readable.

3. A timestamp can be correct and still be interpreted incorrectly

If an event appears in 1970, first check the unit before changing a timezone setting.

console.log(new Date(1700000000).toISOString());
// 1970-01-20T16:13:20.000Z: interpreted as milliseconds

console.log(new Date(1700000000 * 1000).toISOString());
// 2023-11-14T22:13:20.000Z: seconds converted to milliseconds

Keep the original value, its documented unit and the UTC representation together. Digit count is a useful hint, not a universal contract. Local-time displays also depend on the viewer's timezone, so compare UTC values when connecting events from different systems.

4. Pretty SQL can reveal an unintended join

Consider a report intended to retain every customer and attach a pending order when present:

SELECT c.id, o.id
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.status = 'pending';

For an unmatched customer, o.status is null. The WHERE predicate therefore removes that customer. If you intend to retain every customer while matching only pending orders, move that condition into the join:

SELECT c.id, o.id
FROM customers c
LEFT JOIN orders o
  ON o.customer_id = c.id
 AND o.status = 'pending';

These queries express different results. Test a customer with no orders, one with only a completed order, and one with a pending order. Formatting helps expose the distinction; it cannot certify performance. Use the database's execution plan with representative data for that separate question.

5. Regex flags change the answer

Testing one positive example can hide an anchoring or flag problem. Start with multiple matches and a counterexample:

const text = "ORDER-123 noop ORDER-456 ORDER-ABC";
console.log(text.match(/ORDER-\d+/));
// first match: ORDER-123
console.log(text.match(/ORDER-\d+/g));
// ["ORDER-123", "ORDER-456"]
console.log(/^ORDER-\d+$/.test("prefix ORDER-123"));
// false: whole-string validation

JavaScript and other regex engines do not support exactly the same syntax. Check the target engine and escaping rules before copying a pattern into another language. Expensive expressions can also stall a browser tab; a worker with an execution limit is useful for a tester, but not a substitute for reviewing production patterns.

6. Query decoding must preserve repeated values

An encoded plus sign and a literal plus sign are not interchangeable in form-style query parsing. Repeated parameters also matter:

const url = new URL("https://example.com/search?tag=api&tag=java&q=C%2B%2B#section");
console.log(url.searchParams.getAll("tag")); // ["api", "java"]
console.log(url.searchParams.get("q"));      // C++
console.log(new URLSearchParams("q=C++").get("q")); // C followed by two spaces

The fragment is not part of the query sent to the server. When rebuilding a request, preserve repeated values unless the API explicitly requires a single value. Converting the parameters straight into a plain object can discard duplicates.

Keep a small investigation record

For each check, retain the redacted input, expected result, actual result, selected options and environment. That makes the observation reproducible rather than dependent on whichever tool happens to look convincing.

For copyable inputs with expected outputs, use the synthetic fixture pack. It also includes Base64 decoding and a local check script. The unsigned JWT is an expired inspection example, not an authentication credential.

Disclosure: I maintain Developer Debug Tools, a free collection covering these workflows plus SQL formatting, request generation, JSON Schema, Java stacktraces and OpenAPI comparison. Core tool processing runs in the browser; hosting and optional analytics/advertising are separate services.

This article was prepared with AI assistance; its JavaScript examples and SQL join fixture were checked locally.

References: JSON specification, JWT specification, PostgreSQL join semantics, JavaScript match, URLSearchParams.

10 Free Browser Tools Every Backend Developer Should Bookmark

Ali Aygör — Sun, 07 Jun 2026 20:43:00 +0000

As a backend developer, I constantly switch between small utility websites.

Formatting JSON, decoding JWTs, testing regex patterns, converting timestamps...

After years of using the same tools, here are the 10 browser-based utilities I use most often.

1. JSON Formatter

Still my most used tool. Essential for API debugging and log inspection.

2. JWT Decoder

Quickly inspect claims, expiration dates and payload data without writing code.

3. SQL Formatter

Makes large SQL queries much easier to read and review.

4. Regex Tester

Perfect for validating patterns before putting them into code.

5. Timestamp Converter

A daily tool when investigating logs and production issues.

...

Why I Built My Own Toolkit

Switching between 10 different websites became annoying.

So I built a free browser-based toolkit that brings these utilities together in one place:

https://developerdebugtools.com

No signup. No installation. Just open and use.

What browser-based tool do you use most often?

I built a free browser-based developer debugging toolkit

Ali Aygör — Sat, 16 May 2026 23:10:49 +0000

As a backend developer, I kept wasting time switching between random tools for JSON formatting, JWT decoding, regex testing, SQL formatting, Base64 encoding, timestamps, API debugging, and log inspection.

So I built my own browser-based toolkit that brings these practical tools together in one place: