The Ultimate Guide to Fixing Escaped JSON, JWTs, Epoch Timestamps & Stack Traces in Logs

Definition: What Are We Fixing?

Escaped JSON is JSON that has been turned into a string and escaped for embedding (e.g. backslash before quotes). JWTs (JSON Web Tokens) are base64url-encoded header.payload.signature strings that need decoding to read claims. Epoch timestamps are Unix seconds or milliseconds (e.g. 1740932654000) that need converting to human-readable dates. Stack traces in logs are multi-line error backtraces that often contain local file paths (e.g. /Users/yourname/project)— fixing means unescaping, decoding, converting, and optionally scrubbing those paths for safe sharing.

What You See in Raw Logs

In a single log line you might see: (1) A top-level JSON object whose context or payload field is a string full of escaped quotes and backslashes—that’s escaped/nested JSON. (2) An auth or token field with a long base64-like string in three dot-separated parts—that’s a JWT. (3) A timestamp or iat as a number like 1740932654000—epoch milliseconds. (4) An exception or stack field with newlines and paths like /Users/john/app/src/index.js—that’s a stack trace. Fixing means turning each of these into a readable, usable form without losing structure.

When Do These Show Up?

Escaped JSON appears when logging frameworks or message queues serialize objects to strings (e.g. for a single log line or event payload). JWTs appear in auth headers, API responses, and log context when requests are logged. Epoch timestamps are common in system logs, analytics, and JWT iat/exp claims. Stack tracesappear in error logs when exceptions are caught and logged. So you see them together in API logs, error reports, and event streams—anywhere structured logging mixes JSON, auth, time, and errors.

How to Fix: Processing Flow

A robust fix follows a clear order so that one step doesn’t break another: first unescape and parse JSON, then detect and decode JWTs and epoch, then scrub paths in strings (e.g. stack traces).

1. Unescape and parse. Recursively parse string values that look like JSON (start with { or [) until you have a full object tree. Use a depth limit (e.g. 10) to avoid runaway parsing.
2. Decode JWTs. For strings that match JWT shape (three base64url segments) and decode to a header with alg, decode header and payload. Optionally mask PII (sub, name, email) in the payload for safe sharing.
3. Convert epoch. For numbers that look like 10- or 13-digit Unix time (e.g. 1xxxxxxxxx), show human-readable ISO date alongside the original value.
4. Scrub paths. In string values (including stack traces), replace usernames in paths like /Users/username/ or C:\Users\username\ with ~ so logs are safe to share without exposing local identities.

Why This Order and One Tool?

Doing unescape first gives you real objects so JWT and epoch detection run on the right fields (e.g. context.request.auth and timestamp). Decoding before scrubbing keeps JWT payload structure intact; then path scrubbing cleans stack traces and any path-like strings. One pipeline means one paste, one click, and one sanitized output—no switching between unescaper, jwt.io, epoch converter, and manual find-replace. That speeds debugging and reduces the risk of leaking tokens or paths when you share logs with teammates or AI.

Safe Sharing and Export

Logs often contain tokens, paths, and PII. Before pasting into chat, tickets, or AI: use a sanitized export that replaces JWTs with a placeholder (e.g. [JWT]), converts epoch to readable dates, and scrubs paths. That way you keep the structure and timing without exposing secrets or local identities. Prefer client-side-only tools so the log never leaves your machine until it’s already sanitized.

JWT and Epoch in More Detail

JWT: Only treat a string as a JWT if it has three dot-separated segments, each valid base64url, and the first segment decodes to a JSON object with an alg field. That avoids false positives (e.g. hostnames like a.b.c). Extract the token from Bearer <token> when present. Epoch: 10 digits = seconds (e.g. 1516239022); 13 digits = milliseconds (e.g. 1740932654000). Restrict to plausible date ranges (e.g. 2015–2035) to avoid matching random numbers. Confidence scoring (e.g. 0.8 for plausible epoch) helps future tooling (e.g. risk or PII flags).

Quick Reference