DEV Community: ToolZenhub

Unix Timestamp Bugs in JavaScript: Seconds, Milliseconds, and Time Zones Explained

ToolZenhub — Wed, 28 Oct 2026 04:30:00 +0000

You inspect an API response and find this:

{
  "userId": 1042,
  "createdAt": 1700000000,
  "lastLogin": 1700000000000
}

Both fields represent Unix timestamps.

Both contain numbers.

But one is measured in seconds, and the other in milliseconds.

If you handle them incorrectly, your application might display a date in 1970, create a completely unrealistic future date, or incorrectly decide that an authentication token has expired.

These bugs are especially frustrating because the timestamps look valid.

Let's investigate how they happen, how to fix them in JavaScript, and how to debug timestamps more quickly.

1. What exactly is a Unix timestamp?

A Unix timestamp represents elapsed time since the Unix epoch:

January 1, 1970, at 00:00:00 UTC.

It represents an instant in time, independent of how that instant is displayed in different time zones.

For example:

1700000000

This timestamp, measured in seconds, represents:

2023-11-14 22:13:20 UTC

The same instant in India is:

2023-11-15 03:43:20 IST

The underlying instant hasn't changed.

Only its local representation has changed.

That distinction is essential when working with APIs, logs, authentication tokens, databases, and international applications.

2. The most common mistake: seconds vs milliseconds

Unix timestamps are commonly represented in two units:

Seconds
Milliseconds

JavaScript's Date constructor expects a numeric timestamp in milliseconds.

Many backend APIs, including systems that use Unix seconds, provide timestamps in seconds.

This difference creates one of the most common timestamp bugs.

Incorrect example

const timestamp = 1700000000;

const date = new Date(timestamp);

console.log(date.toISOString());

Output:

1970-01-20T16:13:20.000Z

That is probably not the date you expected.

The problem is that JavaScript interpreted the value as milliseconds.

Correct example

const timestampInSeconds = 1700000000;

const date = new Date(
  timestampInSeconds * 1000
);

console.log(date.toISOString());

Output:

2023-11-14T22:13:20.000Z

Multiplying by 1,000 converts seconds into milliseconds.

The reverse mistake

What happens if you multiply an existing millisecond timestamp by 1,000?

const timestampInMilliseconds = 1700000000000;

const incorrectDate = new Date(
  timestampInMilliseconds * 1000
);

console.log(Number.isNaN(incorrectDate.getTime()));

Output:

true

The resulting numeric value exceeds JavaScript's supported Date range.

This is why blindly multiplying timestamps is dangerous.

The correct solution is to know the timestamp's unit before converting it.

3. Why guessing from the number of digits can fail

You might have seen code like this:

function convertTimestamp(value) {
  const milliseconds =
    String(value).length === 10
      ? value * 1000
      : value;

  return new Date(milliseconds);
}

This might work for common modern timestamps.

But it is not a reliable universal solution.

Why?

Because timestamp length depends on the timestamp's value and unit.

For example:

Negative timestamps represent dates before the Unix epoch.
Earlier positive timestamps may have fewer digits.
Larger timestamps may have more digits.
Some systems use microseconds or nanoseconds.

A reliable API should document which unit it returns.

When possible, make the unit explicit in your code.

function fromUnixSeconds(seconds) {
  if (!Number.isFinite(seconds)) {
    throw new TypeError(
      "Expected a finite number of seconds"
    );
  }

  const date = new Date(seconds * 1000);

  if (Number.isNaN(date.getTime())) {
    throw new RangeError("Timestamp is outside Date range");
  }

  return date;
}

function fromUnixMilliseconds(milliseconds) {
  if (!Number.isFinite(milliseconds)) {
    throw new TypeError(
      "Expected a finite number of milliseconds"
    );
  }

  const date = new Date(milliseconds);

  if (Number.isNaN(date.getTime())) {
    throw new RangeError("Timestamp is outside Date range");
  }

  return date;
}

console.log(
  fromUnixSeconds(1700000000).toISOString()
);

console.log(
  fromUnixMilliseconds(1700000000000).toISOString()
);

Both return:

2023-11-14T22:13:20.000Z

These functions make the expected unit clear.

For production applications, also validate whether the input is an integer and whether it matches your API's contract.

4. A real-world bug: Authentication token expiration

Suppose your backend returns an expiration timestamp:

{
  "accessToken": "example-token",
  "expiresAt": 1700003600
}

Assume the API contract specifies that expiresAt is measured in Unix seconds.

You want to determine whether the token has expired.

Incorrect comparison

const expiresAt = 1700003600;

const expired = Date.now() >= expiresAt;

console.log(expired);

The problem?

Date.now() returns milliseconds.

expiresAt is in seconds.

You're comparing two different units.

The result will be incorrect for many real-world scenarios.

Correct comparison

const expiresAtSeconds = 1700003600;

const expiresAtMilliseconds =
  expiresAtSeconds * 1000;

const isExpired =
  Date.now() >= expiresAtMilliseconds;

console.log(isExpired);

Now both values use milliseconds.

For real authentication systems, expiration checks may also incorporate clock skew or a safety margin.

And remember: decoding a JWT's expiration claim does not validate its signature or establish that the token is trustworthy.

Only trusted, properly verified token data should drive security decisions.

5. Unix timestamps and time zones

Here's another common misunderstanding:

A Unix timestamp does not have a time zone.

It identifies a particular instant.

Time zones determine how that instant is displayed to people.

Consider:

const timestamp = 1700000000;

const date = new Date(timestamp * 1000);

console.log(date.toISOString());

Output:

2023-11-14T22:13:20.000Z

Now display the same instant in India:

const indiaTime = new Intl.DateTimeFormat(
  "en-IN",
  {
    timeZone: "Asia/Kolkata",
    dateStyle: "medium",
    timeStyle: "medium",
    hourCycle: "h23"
  }
).format(date);

console.log(indiaTime);

The exact presentation depends on locale formatting rules, but the time corresponds to:

15 Nov 2023, 03:43:20 IST

Now consider New York:

const newYorkTime = new Intl.DateTimeFormat(
  "en-US",
  {
    timeZone: "America/New_York",
    dateStyle: "medium",
    timeStyle: "medium"
  }
).format(date);

console.log(newYorkTime);

The time corresponds to:

November 14, 2023, 5:13:20 PM EST

One instant.

Different local times.

Neither representation changes the timestamp.

Practical rule

Store and transmit unambiguous instants.

Convert them into an appropriate time zone when displaying information to users.

And avoid assuming that every time zone has a fixed UTC offset all year.

6. Daylight saving time makes things more complicated

Consider this local time:

2026-11-01 01:30
America/New_York

On this date, New York transitions from daylight saving time to standard time.

The local clock repeats the hour between 1:00 AM and 2:00 AM.

That means 1:30 AM occurs twice.

The two possible instants are:

2026-11-01T05:30:00Z
2026-11-01T06:30:00Z

They have different UTC offsets:

01:30 EDT (UTC-04:00)
01:30 EST (UTC-05:00)

Simply specifying "1:30 AM in New York" is not enough to identify a unique instant.

This matters when building:

Meeting schedulers
Automated jobs
Booking systems
Financial transaction logs
Monitoring applications

A robust system must define what happens when a local time is repeated or skipped.

For instance, on the spring daylight-saving transition, certain local times do not exist at all.

Time-zone conversion should preserve the instant, while local-time interpretation must account for ambiguity.

7. Debugging timestamps without writing temporary scripts

Sometimes you're not building date-handling logic.

You simply need to investigate a production log, inspect an API response, or check a timestamp from a database.

Writing a temporary JavaScript script every time can become repetitive.

This is one reason I built the Unix Timestamp Converter as part of ToolZenHub.

You can use it here:

https://toolzenhub.in/tools/unix-timestamp-converter/

It runs directly in your browser.

Let's walk through the earlier example.

Step 1: Enter the timestamp

Paste:

1700000000

Step 2: Confirm the unit

Select Seconds.

The tool also provides an automatic unit-detection option, but explicitly selecting the unit is useful when you already know the API contract.

Step 3: Choose your time zone

Select the time zone in which you want to inspect the timestamp.

For example:

Asia/Kolkata

The converted time corresponds to:

15 November 2023
03:43:20 IST

Step 4: Compare the same instant across zones

The converter supports displaying the same timestamp in multiple time zones.

This can be useful when investigating an event involving users or servers in different countries.

Step 5: Convert a date back into a timestamp

You can also enter a date and time with its time zone and convert it into a Unix timestamp.

This is particularly useful when preparing test data or checking scheduled events.

The tool explains ambiguous or nonexistent daylight-saving times rather than silently choosing an interpretation.

8. Debugging multiple timestamps from logs

Now imagine you receive these timestamps:

You want to understand the event sequence.

You could write a script:

const timestamps = [
  1700000000,
  1700000300,
  1700000600,
  1700000900
];

const events = timestamps.map((timestamp) => ({
  timestamp,
  utc: new Date(timestamp * 1000).toISOString()
}));

console.table(events);

This works well for reusable automation.

But sometimes you only need a quick investigation.

ToolZenHub's Unix Timestamp Converter also supports batch conversion.

You can paste multiple timestamp values or compatible log lines.

The tool supports up to 200 values in one batch and uses the selected time zone for the results.

This helps avoid repeatedly converting individual timestamps during a debugging session.

For very large log files, a dedicated script or approved log-analysis system is more appropriate.

9. What about microseconds and nanoseconds?

Not every system uses seconds or milliseconds.

Some databases and telemetry systems represent timestamps with microsecond or nanosecond precision.

For the same example instant:

Unit	Timestamp
Seconds	`1700000000`
Milliseconds	`1700000000000`
Microseconds	`1700000000000000`
Nanoseconds	`1700000000000000000`

A critical problem arises when working with large integers in JavaScript.

JavaScript's standard Number type cannot represent every integer above:

9007199254740991

This is Number.MAX_SAFE_INTEGER.

Modern nanosecond timestamps commonly exceed that limit.

For example:

const timestamp = 1700000000000000000;

console.log(Number.isSafeInteger(timestamp));

Output:

false

This means you should not assume that converting a nanosecond timestamp to Number preserves its exact integer value.

Use BigInt when exact integer arithmetic is required

const nanoseconds = 1700000000000000000n;

const milliseconds =
  nanoseconds / 1000000n;

console.log(milliseconds.toString());

Output:

1700000000000

This example produces exact millisecond precision because the original timestamp is an exact multiple of one million nanoseconds.

For timestamps with sub-millisecond components, integer division drops the remainder unless you preserve it separately.

Also note that native JavaScript Date objects only represent time at millisecond precision.

If your application needs exact microsecond or nanosecond values, preserve those values in an appropriate integer or timestamp representation rather than relying solely on Date.

The ToolZenHub converter supports seconds, milliseconds, microseconds, and nanoseconds, including exact handling of large timestamp values.

10. A safer approach to API timestamp design

A major source of timestamp bugs is unclear API documentation.

Consider this response:

{
  "createdAt": 1700000000
}

The client has to guess the unit.

A clearer contract could use an explicitly named field:

{
  "createdAtUnixSeconds": 1700000000
}

Another option is an unambiguous ISO 8601 timestamp:

{
  "createdAt": "2023-11-14T22:13:20Z"
}

Both approaches can work.

The important part is consistency.

For an API contract, document:

Whether the timestamp represents an instant or a local date and time.
The unit used for numeric timestamps.
The expected precision.
The accepted date range.
How time zones are handled.
Whether missing or invalid timestamps are allowed.

This makes client implementations and automated tests more predictable.

11. A practical timestamp-debugging checklist

When you encounter a suspicious timestamp, check the following:

1. What is the original value?

Avoid converting the value before recording what the API actually returned.

2. What unit does the API use?

Seconds, milliseconds, microseconds, or nanoseconds?

3. Is the timestamp within the expected range?

An application created in 2026 probably shouldn't have an ordinary creation timestamp in 1970.

4. Are you mixing Date.now() with Unix seconds?

Remember that Date.now() uses milliseconds.

5. Are you parsing a date with an explicit UTC offset?

For example:

2026-10-28T10:00:00+05:30

This identifies an instant.

A local date-time string without an offset may require a separate time-zone interpretation.

6. Does daylight saving apply?

Some local times are ambiguous or nonexistent.

7. Are you losing precision?

Be especially careful when processing microsecond and nanosecond timestamps.

8. Are the expected and actual values using the same unit?

Never compare seconds directly with milliseconds.

Final thoughts

Unix timestamps are simple in principle.

But timestamp bugs often arise from hidden assumptions:

Assuming a number is measured in milliseconds.
Guessing units from digit count.
Mixing local time with UTC.
Ignoring daylight-saving transitions.
Losing precision when handling large integers.
Comparing values expressed in different units.

A little clarity around units and time zones prevents many of these problems.

For reusable application logic, write explicit conversion functions and automated tests.

For quick investigation, a timestamp converter can make debugging faster.

If you need to inspect API timestamps, compare time zones, or convert several log entries, you can try the ToolZenHub utility I maintain:

https://toolzenhub.in/tools/unix-timestamp-converter/

The goal isn't to replace understanding with another tool.

It's to remove repetitive conversion work so you can focus on the actual issue.

References

Disclosure: I maintain ToolZenHub, the tool website referenced in this tutorial. This article was created with AI assistance and should be reviewed for technical accuracy before publication.

JWT Decoding vs Verification: Debug Token Expiration Without Making Security Mistakes

ToolZenhub — Sun, 25 Oct 2026 04:30:00 +0000

You open your browser's developer tools, inspect an API request, and find an authorization header:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

The API responds with:

HTTP/1.1 401 Unauthorized

Your first question is probably:

Has the token expired, or is something else wrong?

You could copy the token, decode its payload, and inspect the expiration claim.

But there's an important security distinction that every developer and API tester should understand:

A JWT that decodes successfully is not necessarily a valid or trustworthy token.

Let's investigate what JWTs contain, how to troubleshoot authentication failures, and when decoding is useful versus when signature verification is essential.

1. What exactly is a JWT?

JWT stands for JSON Web Token.

A common signed JWT format contains three parts separated by periods:

HEADER.PAYLOAD.SIGNATURE

For example, a JWT might look like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

This example comes from the JWT standard, RFC 7519.

The three segments have different responsibilities.

Segment	Purpose
Header	Describes token metadata, including the declared signing algorithm
Payload	Contains claims about the token's subject and other information
Signature	Provides integrity and authenticity evidence when correctly verified

The header and payload are commonly JSON objects encoded using Base64URL.

They are not automatically encrypted.

Anyone possessing the token can generally decode those two parts.

That is why you should never place confidential information inside a normal signed JWT merely because its contents look unreadable.

2. Decoding a JWT is easy

Let's decode the sample token using JavaScript.

We will only inspect its contents.

We will not claim to verify its authenticity.

For this example, use a modern JavaScript runtime that supports atob() and TextDecoder.

const token =
  "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9." +
  "eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ." +
  "SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c";

function decodeBase64UrlJson(segment) {
  const base64 = segment
    .replace(/-/g, "+")
    .replace(/_/g, "/");

  const padding =
    "=".repeat((4 - (base64.length % 4)) % 4);

  const binary = atob(base64 + padding);

  const bytes = Uint8Array.from(
    binary,
    char => char.charCodeAt(0)
  );

  return JSON.parse(
    new TextDecoder("utf-8", {
      fatal: true
    }).decode(bytes)
  );
}

const parts = token.split(".");

if (parts.length !== 3) {
  throw new Error("Expected a three-part JWT");
}

const header = decodeBase64UrlJson(parts[0]);
const payload = decodeBase64UrlJson(parts[1]);

console.log(header);
console.log(payload);

The decoded header is:

{
  "alg": "HS256",
  "typ": "JWT"
}

The decoded payload is:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

Notice something important.

We decoded the header and payload without using a secret key.

This is expected behavior.

Decoding reveals what the token says. It does not establish whether those statements are true.

Our example function is a learning aid, not a security validator or complete JWT parser.

3. Why decoding alone is dangerous

Imagine an API receives a token containing:

{
  "sub": "user-123",
  "role": "admin"
}

A developer might decode the payload and use the role value to grant administrative access.

That would be unsafe.

A token's contents can be modified or forged.

Without proper cryptographic verification, the server cannot assume the claims came from a trusted issuer.

For example, this is insecure application logic:

// INSECURE EXAMPLE — DO NOT USE FOR AUTHORIZATION

const payload = decodeBase64UrlJson(
  token.split(".")[1]
);

if (payload.role === "admin") {
  // Never grant privileges on this basis.
}

The application trusts unverified data.

An attacker may create a token that claims any role they want.

The important defense is to verify the token using a trusted cryptographic key and enforce the application's expected token requirements.

4. What does signature verification actually do?

JWT signatures are intended to protect the signed contents against unauthorized modification.

For example, when a token uses HS256, a trusted issuer signs the token using a shared secret.

When a token uses RS256, it is typically signed with a private key and verified with the corresponding public key.

Verification checks whether the signature is valid under the expected algorithm and trusted key.

But signature verification is only part of secure token handling.

Applications may also need to validate:

Issuer
Audience
Expiration
Not-before time
Token type
Required claims
Accepted algorithms
Revocation or session state

A token with a mathematically valid signature may still be inappropriate for a particular application.

For example, it may have been issued for a different audience.

Cryptographic validity and authorization are not the same thing.

5. Never trust the algorithm declared by the token

A JWT header might contain:

{
  "alg": "HS256"
}

Or:

{
  "alg": "none"
}

The token itself is untrusted input.

Your API should not blindly let an incoming token dictate which algorithms are acceptable.

Instead, configure your verification system to accept only the algorithms appropriate for your issuer and application.

For example, if your service expects RS256 tokens from a trusted identity provider, it should not silently switch to another algorithm because the incoming token requests it.

The expected algorithm, key selection, issuer, and audience should come from trusted application configuration.

OWASP specifically warns against relying on untrusted JWT header information to determine the verification algorithm.

6. How JWT expiration works

Now consider a token payload containing:

{
  "sub": "user-123",
  "iat": 1792886400,
  "exp": 1792890000
}

Two fields matter here:

iat: Issued at
exp: Expiration time

JWT time claims use NumericDate values, measured in seconds since the Unix epoch.

JavaScript's Date.now() returns milliseconds.

That difference can introduce subtle bugs.

Incorrect expiration check

const exp = 1792890000;

const expired = Date.now() >= exp;

This compares milliseconds with seconds.

The result is not meaningful.

Correct unit comparison

const exp = 1792890000;

const expirationMilliseconds = exp * 1000;

const expired =
  Date.now() >= expirationMilliseconds;

console.log(expired);

Now both values use milliseconds.

However, this is only a comparison of an expiration number.

It does not authenticate the token.

A malicious token could contain an expiration date far in the future.

Always perform actual token verification using a trusted system before treating expiration claims as authoritative.

7. Understand the important registered claims

JWTs can contain several standard claims.

Here are seven commonly encountered ones.

Claim	Meaning
`iss`	Issuer
`sub`	Subject
`aud`	Audience
`exp`	Expiration time
`nbf`	Not before
`iat`	Issued at
`jti`	JWT identifier

For example:

{
  "iss": "https://auth.example.com",
  "sub": "user-123",
  "aud": "orders-api",
  "iat": 1792886400,
  "nbf": 1792886400,
  "exp": 1792890000,
  "jti": "token-abc-123"
}

This payload claims:

The issuer is an authentication service.
The subject is user-123.
The intended audience is orders-api.
The token has issuance, validity-start, and expiration times.
The token has an identifier.

But remember: before verification, these are merely claims.

The decoder cannot establish their authenticity.

8. Debugging a 401 Unauthorized response

Suppose your automated API test suddenly starts failing:

GET /api/orders

HTTP/1.1 401 Unauthorized

Your request includes an access token.

You suspect an expiration issue.

A structured investigation might look like this.

Step 1: Confirm the token was sent

Check whether your request contains an authorization header.

For example:

Authorization: Bearer <access-token>

Do not print a real token into publicly accessible logs.

Step 2: Check the token's structure

A common compact signed JWT contains three dot-separated segments.

However, not every access token is a JWT.

Some systems use opaque tokens that cannot be decoded locally.

Encrypted JWTs can also have a different structure.

Step 3: Inspect the claims

For a suitable test token, inspect exp, nbf, iss, and aud.

Ask whether the values are consistent with your expectations.

Step 4: Confirm the server's validation rules

Check the expected issuer, audience, algorithm, and trusted keys.

A failure can occur even when the expiration time appears reasonable.

Step 5: Check clock-related issues

A mismatch between application and identity-provider clocks can affect time-based checks.

Some verification systems allow a small, explicitly configured clock tolerance.

Step 6: Review the authentication workflow

Perhaps the token was never refreshed, the wrong environment was used, or a session was revoked.

Don't assume every 401 response is caused by expiration.

The response and the server-side verification logs should guide the investigation.

9. A browser-based way to inspect JWT claims

For quick debugging, writing a temporary decoding script every time can become repetitive.

I maintain ToolZenHub, a collection of practical browser-based utilities.

One of them is a JWT Decoder:

https://toolzenhub.in/tools/jwt-decoder/

It is designed to help developers inspect token contents without confusing decoding with signature verification.

Here's a practical walkthrough.

Step 1: Open the JWT Decoder

Visit the link above.

Step 2: Load a safe example

Select Load an example, or paste a synthetic, expired, or otherwise approved test token.

Avoid copying live production access tokens into debugging tools unless your security policies explicitly permit that use.

Step 3: Decode the token

Select Decode.

The tool displays the readable header and payload.

Step 4: Inspect registered claims

The tool explains standard claims such as:

iss
sub
aud
exp
nbf
iat
jti

This saves the effort of repeatedly converting timestamp claims by hand.

Step 5: Review time information

The tool shows supported time claims as:

UTC date and time.
Date and time in your device's local zone.
Relative time information.

It also identifies values that look like milliseconds instead of the expected JWT seconds.

Step 6: Remember the verification boundary

The tool explicitly labels the signature as not verified.

This is intentional.

It reads token content. It does not authenticate the token, verify its signature, or confirm that an API should accept it.

The tool decodes tokens inside the browser without uploading the input token to ToolZenHub.

That reduces one category of data transfer, but does not make it appropriate to inspect sensitive production tokens on an unapproved device.

10. Why a decoder should not claim that a token is valid

Suppose you decode a token and see:

{
  "sub": "user-123",
  "role": "admin",
  "exp": 4102444800
}

The expiration corresponds to a future date.

Does this mean the token is valid?

No.

The token could have:

An invalid signature.
An untrusted issuer.
The wrong audience.
An unsupported algorithm.
A revoked session.
Forged claims.

A decoder can show what the token claims about itself.

It cannot establish the token's trustworthiness without performing the required verification.

That is why the ToolZenHub decoder does not present its decoded results as proof of validity.

11. Testing JWT-protected APIs with Playwright

Let's consider an API test.

Suppose your application obtains an access token through a supported test authentication workflow.

You can send it with Playwright:

const { test, expect } = require("@playwright/test");

test("authenticated API request", async ({
  request
}) => {
  const token = process.env.TEST_ACCESS_TOKEN;

  if (!token) {
    throw new Error(
      "TEST_ACCESS_TOKEN is not configured"
    );
  }

  const response = await request.get(
    "/api/profile",
    {
      headers: {
        Authorization: `Bearer ${token}`
      }
    }
  );

  expect(response.status()).toBe(200);

  const body = await response.json();

  expect(body).toHaveProperty("id");
});

This example assumes:

A valid base URL is configured.
The endpoint exists.
The token is appropriate for the target environment.
The API response contains an id property.

Do not hardcode live credentials into the test source.

Use appropriate secret-management mechanisms for CI and development environments.

And don't print the token into test reports.

What should you test?

For a JWT-protected API, useful test scenarios may include:

Missing authorization header.
Expired token.
Invalid signature.
Token with the wrong audience.
Token from an untrusted issuer.
Token that is not yet valid.
Valid token with insufficient permissions.
Valid authorized request.

Expected HTTP responses depend on your application's authentication and authorization contract.

For many systems, authentication failures return 401 and authorization failures return 403, but you should verify your own API's documented behavior.

12. What about encrypted JWTs?

So far, we've discussed the common signed JWT format.

But JWT claims can also be represented using JSON Web Encryption (JWE).

A compact JWE typically contains five segments.

A basic decoder cannot simply read its encrypted payload without appropriate decryption material.

ToolZenHub's JWT Decoder recognizes the five-part format and refuses to present encrypted content as though it could decode it.

This is an important distinction.

Base64URL decoding and cryptographic decryption are not the same operation.

13. A useful JWT debugging checklist

When authentication fails, check:

Is the access token present?
Is it a JWT or an opaque token?
Is its structure consistent with the expected token format?
Does the expiration claim use seconds?
Is the token within its claimed validity window?
Does the issuer match your trusted identity provider?
Is the audience correct for your API?
Is the signature verified using an approved algorithm and trusted key?
Does the token contain the required claims?
Does the user have permission for the requested operation?
Has the token or associated session been revoked?
Are sensitive tokens excluded from logs and bug reports?

This helps separate formatting issues, time-related issues, trust failures, and authorization problems.

14. When should you decode and when should you verify?

Here's a useful distinction.

Decode a JWT when:

You're inspecting a test token.
You're debugging the contents of a claim.
You're checking the structure of a token.
You're reading an expiration timestamp.
You're investigating whether an API client received the expected data.

Verify a JWT when:

You're authenticating a request.
You're making an authorization decision.
You're establishing the issuer's authenticity.
You're deciding whether token claims can be trusted.
You're protecting application resources.

A decoder supports investigation.

A verifier helps establish whether the token can be trusted under a particular security policy.

Don't substitute one for the other.

Final thoughts

JWT debugging becomes much easier when you separate three different questions:

What does the token contain?

Decoding helps answer this.

Can the token be trusted?

Signature verification and claim validation help answer this.

Should the application allow this operation?

Authorization rules and application state determine this.

Mixing these questions can create serious security vulnerabilities.

For quick inspection of safe test tokens, you can use the browser-based JWT Decoder I maintain:

https://toolzenhub.in/tools/jwt-decoder/

It displays the token's structure, claims, and timestamps while explicitly warning that the signature is not verified.

The goal is to reduce repetitive debugging work without giving a false sense of security.

References

Disclosure: I maintain ToolZenHub, the website referenced in this article. This article was prepared with AI assistance and requires technical and editorial review before publication.

How to Debug Large JSON API Responses Faster (With a Practical Example)

ToolZenhub — Wed, 21 Oct 2026 04:30:00 +0000

Debugging a JSON API response is not always difficult because of the code.

Sometimes the real problem is simply finding the information you need.

Imagine receiving a response containing hundreds of nested objects, arrays, user records, and metadata fields — all compressed into one long line.

You need to identify one unexpected value, confirm the JSON is valid, and decide whether the problem is with the API response or your application.

How do you investigate without wasting time?

Let's work through a practical example.

1. The problem: A difficult-to-read API response

Imagine you're testing an order-management API.

The endpoint returns the following response:

{"orderId":"ORD-1024","customer":{"id":42,"name":"Alex","address":{"city":"Hyderabad","postalCode":"500001"}},"items":[{"sku":"KB-101","quantity":2,"price":1499},{"sku":"MS-202","quantity":1,"price":799}],"payment":{"status":"completed","amount":3797},"delivery":{"status":"pending","estimatedDays":3}}

This response is valid JSON.

But it's not particularly convenient to inspect.

Suppose your API test fails because the expected delivery status is shipped, while the actual response contains pending.

You know something is different, but navigating a large one-line response can be frustrating.

When responses become significantly larger, the problem grows.

Before writing more debugging code, the first useful step is to make the response readable.

2. Format the JSON before investigating

The same response becomes easier to understand when formatted with indentation.

{
  "orderId": "ORD-1024",
  "customer": {
    "id": 42,
    "name": "Alex",
    "address": {
      "city": "Hyderabad",
      "postalCode": "500001"
    }
  },
  "items": [
    {
      "sku": "KB-101",
      "quantity": 2,
      "price": 1499
    },
    {
      "sku": "MS-202",
      "quantity": 1,
      "price": 799
    }
  ],
  "payment": {
    "status": "completed",
    "amount": 3797
  },
  "delivery": {
    "status": "pending",
    "estimatedDays": 3
  }
}

Now you can quickly identify:

The order identifier.
The customer's information.
The array containing purchased items.
The payment status and amount.
The delivery status.

Formatting doesn't change the underlying data. It changes how easily a developer can inspect its structure.

For a single response, this may save only a little time.

For repeated debugging, readable payloads can make investigations much easier.

3. Inspect nested values using JavaScript

Formatting is useful for visual inspection.

But automated tests need a repeatable way to access specific values.

Suppose the previous response has already been parsed into a JavaScript object named order.

You can inspect individual properties:

console.log(order.orderId);

console.log(order.customer.address.city);

console.log(order.payment.status);

console.log(order.delivery.status);

Expected output:

ORD-1024
Hyderabad
completed
pending

You can also access array values:

console.log(order.items[0].sku);
// KB-101

console.log(order.items[1].quantity);
// 1

For an API tester, this is often the next step after understanding the payload structure.

But there is an important distinction:

Formatting JSON helps you understand the data. Assertions help you verify its behavior.

You need both when debugging a real API.

4. Identify the actual cause of a failed assertion

Consider this Playwright API test:

const { test, expect } = require("@playwright/test");

test("order delivery status", async ({ request }) => {
  const response = await request.get("/api/orders/ORD-1024");

  expect(response.ok()).toBeTruthy();

  const order = await response.json();

  expect(order.delivery.status).toBe("shipped");
});

This test assumes that a configured API endpoint exists and returns the illustrated response.

If the API returns:

{
  "delivery": {
    "status": "pending"
  }
}

The assertion fails.

That failure does not automatically prove the API is defective.

You need to investigate the expected business behavior.

For example:

Should a newly created order already be shipped?
Is the test running before the delivery update finishes?
Does the test use the correct order identifier?
Is the response stale or cached?
Is pending actually the correct state?

This is where good API testing goes beyond checking individual field values.

A failing assertion is evidence of a mismatch between expectations and actual behavior. It is not, by itself, evidence of a backend defect.

5. What if the response is invalid JSON?

Now consider a different response:

{
  "orderId": "ORD-1024",
  "status": "pending",
}

The trailing comma makes this invalid JSON.

JavaScript's JSON.parse() will throw an error:

const responseText = `{
  "orderId": "ORD-1024",
  "status": "pending",
}`;

try {
  const order = JSON.parse(responseText);
  console.log(order);
} catch (error) {
  console.error("JSON parsing failed:", error.message);
}

A parsing error means the text does not follow JSON syntax.

However, it doesn't tell you whether the original problem came from the backend, a copied sample, a test fixture, or some other source.

First identify where the invalid text originated.

Then correct the responsible system or test data.

Avoid automatically modifying an API response merely to make it parse successfully. Doing so can hide genuine defects.

6. A practical browser-based debugging workflow

For JSON that is safe to inspect locally, a browser-based formatter can reduce the need to write temporary formatting scripts.

I maintain ToolZenHub, a collection of practical online utilities.

One of its developer tools is the free JSON Formatter & Validator:

https://toolzenhub.in/tools/json-formatter/

Here's how you can use it with the earlier order response.

Step 1: Copy the JSON payload

Take the one-line response from the first example.

Make sure you are copying the actual JSON response body rather than headers or unrelated console output.

Step 2: Paste it into the tool

Open the JSON Formatter & Validator and paste the response into its input field.

Step 3: Select Format

The tool formats valid JSON using two-space indentation.

This makes nested objects and arrays easier to inspect.

Step 4: Inspect the relevant fields

In our example, look for:

"delivery": {
  "status": "pending",
  "estimatedDays": 3
}

You can now focus on the property involved in the failing assertion.

Step 5: Validate suspicious JSON

If the payload fails to parse, select Validate.

For malformed JSON, the tool reports the error location, including line and column information.

You can use its "Go to error" option to navigate to the problematic location.

The tool identifies syntax problems; it does not silently repair or rewrite invalid JSON.

Step 6: Copy the formatted result when needed

If you need a readable sample for documentation or a test fixture, use Copy output.

For a compact representation, use Minify instead.

These operations serve different purposes:

Operation	Purpose
Format	Improve readability
Minify	Remove unnecessary whitespace
Validate	Check JSON syntax
Copy output	Reuse the processed text

The tool processes JSON in your browser rather than uploading it to ToolZenHub.

Still, follow your organization's data-handling policies. Do not paste confidential production data, credentials, tokens, or personal information into tools unless your security requirements permit it.

7. An important limitation: Valid JSON can still contain wrong data

Suppose the API returns:

{
  "orderId": "ORD-1024",
  "payment": {
    "status": "completed",
    "amount": "3797"
  }
}

This is valid JSON.

A syntax validator should accept it.

But notice that amount is a string.

If the API contract requires a number, this response may be incorrect.

For example:

const order = {
  orderId: "ORD-1024",
  payment: {
    status: "completed",
    amount: "3797"
  }
};

console.log(typeof order.payment.amount);
// string

To validate the value's type:

if (typeof order.payment.amount !== "number") {
  throw new Error("Payment amount must be numeric");
}

This is a separate type check.

JSON formatting and syntax validation do not replace schema validation, application logic, or automated assertions.

A useful debugging workflow should distinguish these different responsibilities.

8. Calculate expected values instead of trusting the response

Let's examine the order items:

const items = [
  {
    sku: "KB-101",
    quantity: 2,
    price: 1499
  },
  {
    sku: "MS-202",
    quantity: 1,
    price: 799
  }
];

We can independently calculate the total:

const total = items.reduce((sum, item) => {
  return sum + item.quantity * item.price;
}, 0);

console.log(total);
// 3797

For this example:

2 × 1499 = 2998
1 × 799  = 799

Total = 3797

This gives the tester an independent expected result.

We can compare that result with the returned payment amount.

const actualPaymentAmount = 3797;

if (total !== actualPaymentAmount) {
  throw new Error("Payment amount mismatch");
}

For real payment systems, also account for discounts, taxes, shipping, currency, refunds, and the application's rounding rules.

A simple item-total calculation should not be treated as a universal payment-validation formula.

9. Avoid logging sensitive API responses

A common debugging habit is to print the entire response:

console.log(order);

That may be convenient in a local test.

But production API responses can contain:

Authentication credentials.
Session tokens.
Personal information.
Addresses and contact details.
Internal identifiers.
Confidential application data.

Instead, log only the fields required for investigation.

console.log({
  orderId: order.orderId,
  deliveryStatus: order.delivery.status
});

Even selected identifiers should be checked against your organization's logging policies.

When sharing debugging examples publicly, use fabricated test data rather than real customer information.

10. When should you use a formatter and when should you write code?

Both approaches are useful.

Use a JSON formatter when:

You want to visually inspect a response.
A nested structure is difficult to read.
You need to locate a JSON syntax problem.
You want a formatted sample for documentation.
You need to remove unnecessary whitespace.

Use automated validation and assertions when:

You're checking API behavior repeatedly.
The API contract specifies required fields.
You need to verify data types.
You need to test calculations or business logic.
You want failures detected automatically in CI.

For large or sensitive datasets, local command-line tools and approved development environments may be more appropriate than a browser utility.

ToolZenHub's formatter has defined input-size and nesting limits, so it is not intended to process arbitrarily large responses.

The two approaches complement each other rather than compete.

11. A repeatable API debugging checklist

The next time an API test fails, work through these questions:

Did the HTTP request reach the expected endpoint?
Was the HTTP status what you expected?
Is the response body valid JSON?
Is the response structure readable?
Does the expected property exist?
Is the property using the correct data type?
Does the returned value match the API contract?
Are there timing, authentication, or test-data issues?
Can you independently verify the important calculation or result?
Are your debugging logs safe to retain or share?

This sequence helps distinguish syntax issues from data issues and actual application defects.

Final thoughts

Debugging APIs efficiently is not about using the most tools or writing the most code.

It's about reducing uncertainty.

Start by understanding the response. Make the structure readable. Check syntax. Inspect relevant properties. Verify the contract. Then investigate the behavior that caused the test to fail.

If formatting or validating JSON is slowing down your workflow, you can try the browser-based utility I maintain at ToolZenHub:

https://toolzenhub.in/tools/json-formatter/

The goal is simple: spend less time untangling raw payloads and more time identifying the actual problem.

Disclosure: I maintain ToolZenHub, the website referenced in this article. This tutorial was prepared with AI assistance and requires editorial and technical review before publication.

5 Common JSON Mistakes That Break API Requests (With Fixes)

ToolZenhub — Sat, 17 Oct 2026 18:27:21 +0000

JSON is one of the most common formats used to exchange data between frontend applications, backend services, and APIs.

It looks similar to a JavaScript object, but JSON has stricter syntax rules.

A small mistake can cause a request body to fail parsing, produce an HTTP 400 response, or prevent automated tests from running correctly.

Here are five common mistakes, how to fix them, and how to catch them before sending an API request.

1. Using single quotes instead of double quotes

Incorrect JSON

{
  'name': 'Ram',
  'role': 'QA Engineer'
}

JSON requires double quotes around property names and string values.

Correct JSON

{
  "name": "Ram",
  "role": "QA Engineer"
}

JavaScript permits single-quoted strings in object literals. JSON does not.

2. Adding trailing commas

Incorrect JSON

{
  "name": "Ram",
  "skills": ["JavaScript", "Playwright"],
}

The comma after the array is not allowed.

Correct JSON

{
  "name": "Ram",
  "skills": ["JavaScript", "Playwright"]
}

Trailing commas are permitted in many JavaScript object and array literals, but not in standard JSON.

3. Including comments inside JSON

Incorrect JSON

{
  // Application configuration
  "environment": "test",
  "retries": 3
}

Standard JSON does not support comments.

Correct JSON

{
  "environment": "test",
  "retries": 3
}

Some configuration formats support comments, but those are extensions and should not be assumed to work in a JSON API request.

4. Writing JavaScript values that JSON does not support

Incorrect JSON

{
  "user": undefined,
  "createdAt": new Date(),
  "score": NaN
}

These are JavaScript values or expressions, not valid JSON values.

JSON supports:

Strings
Numbers
Booleans
null
Arrays
Objects

Correct JSON

{
  "user": null,
  "createdAt": "2026-10-17T10:30:00Z",
  "score": 0
}

The corrected values are illustrative. A real application must choose values that accurately represent its data, rather than automatically replacing every invalid value with zero or null.

5. Forgetting to escape special characters

Incorrect JSON

{
  "message": "He said "Hello" to me"
}

The internal quotation marks terminate the string unexpectedly.

Correct JSON

{
  "message": "He said \"Hello\" to me"
}

Similarly, backslashes and certain control characters need to be escaped correctly.

For example:

{
  "folder": "C:\\Users\\Public",
  "message": "Line one\nLine two"
}

How to validate JSON using JavaScript

JavaScript provides JSON.parse() for parsing JSON text.

const payload = `{
  "name": "Ram",
  "active": true
}`;

try {
  const data = JSON.parse(payload);

  console.log("Valid JSON");
  console.log(data);
} catch (error) {
  console.error("Invalid JSON:", error.message);
}

If the input is invalid, JSON.parse() throws a SyntaxError.

This is useful when validating JSON received as text.

However, valid JSON syntax does not guarantee that an API accepts the data.

For example, this is valid JSON:

{
  "email": 123
}

But an API might require email to be a string.

That is a schema or business-validation issue, not a JSON syntax issue.

How to send JSON with fetch()

When sending JSON in an HTTP request, serialize a JavaScript object using JSON.stringify().

const payload = {
  name: "Ram",
  active: true
};

const response = await fetch("/api/users", {
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify(payload)
});

console.log(response.status);

Here, /api/users is an illustrative endpoint. Replace it with a valid endpoint for your application.

JSON.stringify() converts the JavaScript object into JSON text.

This helps avoid common errors from manually constructing request bodies.

Remember that JSON.stringify() also has specific behavior for values such as undefined, functions, and non-finite numbers. It is not a substitute for checking that your data matches an API's expected schema.

Quick debugging checklist

Before sending a JSON payload:

Check that keys and string values use double quotes.
Remove trailing commas.
Remove comments.
Check for unsupported values.
Escape special characters correctly.
Validate the JSON syntax.
Confirm that property names and data types match the API contract.
Verify the request's Content-Type header when sending JSON.

Final thoughts

JSON mistakes are easy to overlook, especially when working with API automation, JavaScript, and test data.

Understanding the difference between JavaScript object syntax, valid JSON, and API schema validation can save time during debugging.

The most reliable approach is to construct data using normal JavaScript objects, serialize when necessary, validate incoming JSON, and test against the API's expected contract.

This article was prepared with AI assistance and should be reviewed for technical accuracy before publication.