DEV Community: Tahmid

How to Convert JSON to YAML (and Back) Without Writing a Single Line of Code

Tahmid — Sun, 03 May 2026 01:30:10 +0000

You're staring at a JSON API response and you need to paste it into a Kubernetes ConfigMap. Or your colleague sent you a YAML Helm values file and your integration test expects JSON. Either way, manually rewriting the format is tedious, error-prone, and a genuine waste of your afternoon.

This is one of those tasks that sounds simple but hides dozens of small traps: indentation levels, quoted strings that need to stay quoted, booleans that change meaning, and nested arrays that look completely different in each format. Let's fix it properly.

Why JSON and YAML Keep Colliding

JSON and YAML represent the same data model — key-value pairs, arrays, nested objects — but they express it differently. JSON uses braces and brackets; YAML uses indentation and dashes. This makes them structurally compatible but visually incompatible.

The collision happens most often in these real-world scenarios:

API responses → Kubernetes manifests. You fetch config data from an API (JSON) and need to embed it in a ConfigMap or Secret (YAML).
GitHub Actions / CI pipelines. Workflow files are YAML, but tool configs (ESLint, Prettier, TypeScript) often live in JSON.
Helm chart values. Default values are YAML; your templating logic might generate JSON alongside them.
Ansible playbooks. Variables defined in JSON need to flow into YAML playbook tasks.

The Conversion Is Mechanical — But Still Fiddly

Here's what the same data looks like in both formats:

JSON:

{
  "server": {
    "host": "api.example.com",
    "port": 8080,
    "tls": true
  },
  "retries": 3,
  "tags": ["production", "us-east-1"]
}

YAML equivalent:

server:
  host: api.example.com
  port: 8080
  tls: true
retries: 3
tags:
  - production
  - us-east-1

Notice the changes: no braces, no quotes around plain strings, arrays become dash-prefixed lists, and the entire structure depends on consistent indentation. One wrong space and your YAML parser throws a fit.

Going the other direction is just as mechanical — but converting by hand still risks mistakes, especially with deeply nested objects.

Converting in the Browser: The Fast Path

Instead of writing conversion code every time, the JSON to YAML Converter handles this in your browser. Paste your JSON on the left, get clean YAML on the right. No sign-up, nothing leaves your browser.

Before converting, make sure your JSON is valid. Compacted API responses or copied-from-logs JSON often have hidden issues — trailing commas, unescaped characters, or single quotes instead of double. Running it through the JSON Beautifier & Validator first formats and validates it in one step, so you're not feeding broken JSON into a converter and wondering why the output looks wrong.

A Real-World Example: Kubernetes ConfigMap

Let's say you have this JSON config coming out of a deployment pipeline:

{
  "database": {
    "host": "postgres.internal",
    "port": 5432,
    "name": "app_production",
    "ssl_mode": "require"
  },
  "cache": {
    "ttl": 300,
    "max_size": 1000
  },
  "feature_flags": {
    "new_checkout": true,
    "beta_search": false
  }
}

After conversion, you get YAML you can drop directly into a Kubernetes ConfigMap:

database:
  host: postgres.internal
  port: 5432
  name: app_production
  ssl_mode: require
cache:
  ttl: 300
  max_size: 1000
feature_flags:
  new_checkout: true
  beta_search: false

Clean, indented, and ready to embed. The tool handles the structural mapping — you just verify the output makes sense.

Going the Other Way: YAML Back to JSON

The reverse conversion matters just as much. Your GitHub Actions workflow file is YAML; you want to parse specific values in a script that expects JSON. Or a colleague sends you an Ansible vars file and your test harness is JSON-only.

The same JSON to YAML Converter supports bidirectional conversion — paste YAML in the YAML panel and get JSON back.

One thing to watch for when going YAML → JSON: YAML has native support for timestamps, multi-line strings (| and > blocks), and anchors/aliases (& and *). These don't have direct JSON equivalents, so they get serialized as plain strings or resolved inline. If your YAML uses these features heavily, review the JSON output carefully before using it downstream.

When to Write the Conversion in Code

For a one-off config tweak, the browser tool is the fastest path. But if you're converting as part of a build pipeline or automation script, you'll want code. Here's the idiomatic approach in a couple of common languages:

Python:

import json, yaml

with open("config.json") as f:
    data = json.load(f)

with open("config.yaml", "w") as f:
    yaml.dump(data, f, default_flow_style=False)

Node.js (with js-yaml):

const fs = require('fs');
const yaml = require('js-yaml');

const data = JSON.parse(fs.readFileSync('config.json', 'utf8'));
fs.writeFileSync('config.yaml', yaml.dump(data));

For interactive exploration or debugging — especially when you're unsure why a converted file looks off — the browser tool remains the quickest feedback loop even if you have automation in place.

What Format Mismatch Do You Hit Most?

I'm curious — is it mostly the API → config file direction that catches you out, or is YAML → JSON (for testing or scripting) the bigger pain point in your workflow? Drop a comment below.

Free tools used in this post:

JSON to YAML Converter — converts between JSON and YAML formats instantly in the browser, bidirectional
JSON Beautifier & Validator — formats and validates JSON before you convert, catching hidden errors fast
All tools — client-side, no sign-up, nothing leaves your browser

How to Query Nested JSON with JSONPath (Without Writing Loops)

Tahmid — Sun, 03 May 2026 01:21:33 +0000

You just got back a 300-line API response. Somewhere inside three levels of nesting is the email field you actually need. So you write a loop, then another loop, then a conditional — and now you're maintaining brittle traversal code that breaks every time the API schema shifts.

There's a better way: JSONPath.

JSONPath is a query language for JSON, similar to how XPath works for XML. Instead of writing code to traverse a structure, you write a short expression that reads like a path. It works across languages, and once you learn the syntax, you'll reach for it constantly.

The Basics: What JSONPath Looks Like

Here's a typical API response — a list of orders, each with nested customer and item data:

{
  "store": {
    "orders": [
      {
        "id": 1,
        "customer": { "name": "Alice", "email": "alice@example.com" },
        "items": [{"sku": "A1", "qty": 2}, {"sku": "B3", "qty": 1}]
      },
      {
        "id": 2,
        "customer": { "name": "Bob", "email": "bob@example.com" },
        "items": [{"sku": "C7", "qty": 5}]
      }
    ]
  }
}

To get every customer email without writing any loops:

$.store.orders[*].customer.email

Result:

["alice@example.com", "bob@example.com"]

The $ represents the root. The . navigates into an object key. [*] means "all array elements." Three characters replace a full nested loop.

Filtering: The Real Power

JSONPath shines when you need to filter by a condition. Say you only want items where qty is greater than 1:

$.store.orders[*].items[?(@.qty > 1)]

Result:

[
  {"sku": "A1", "qty": 2},
  {"sku": "C7", "qty": 5}
]

The ?() is a filter expression. @ refers to the current node. You can combine conditions with && and ||, check for key existence with @.key, and do string comparisons too.

Here's the equivalent Python — same outcome, but compare the cognitive load:

# Without JSONPath — five lines, easy to get wrong
results = []
for order in data["store"]["orders"]:
    for item in order["items"]:
        if item["qty"] > 1:
            results.append(item)

The JSONPath version is one line and self-documenting. Anyone reading it immediately knows what data you're after.

Recursive Descent: Finding a Key Anywhere in the Tree

Sometimes you don't know exactly where a key lives — you just know it exists somewhere in a deeply nested structure. The .. (recursive descent) operator handles this:

$..email

This finds every email field at any depth in the document. It's invaluable for exploring unfamiliar API schemas or debugging payloads where nesting is inconsistent across records.

Try it live with the JSONPath Evaluator on jsonindenter.com — paste your JSON, type any expression, and see matched results highlighted instantly. No installation, nothing leaves your browser.

A Practical Workflow for Real API Responses

When you're dealing with a large, unfamiliar JSON blob, this three-step routine saves a lot of "why does my query return nothing?" debugging time:

Paste the response into the JSON Beautifier to get a clean indented view and understand the shape of the data.
Run it through the JSON Validator to confirm it's well-formed — a malformed payload will silently produce empty results and send you chasing the wrong problem.
Switch to the JSONPath tool and iterate on your expression until you're extracting exactly what you need.

Quick Reference: Syntax That Covers 80% of Cases

$ — root element
.key — child key
..key — recursive search for key at any depth
[*] — all array elements
[0] — first element; [-1] — last element
[0,2] — elements at index 0 and 2
[?(@.price < 10)] — filter where price is less than 10
@.key — current node's key (used inside filter expressions)

For edge cases and implementation differences across languages, the JSONPath guide on jsonindenter.com covers the full spec with annotated examples worth bookmarking.

When JSONPath Is the Wrong Tool

JSONPath is read-only — it queries and extracts, it doesn't mutate. If you need to patch a JSON document in place (add a field, replace a value, remove a key), that's what JSON Patch is designed for. The two tools are complementary: JSONPath to find, JSON Patch to modify.

Also worth knowing: JSONPath implementations vary across languages. jsonpath-ng in Python, jsonpath-plus in JavaScript, and Jayway in Java each have subtle differences. RFC 9535 (published in 2024) is working to standardize the spec, but for production code it's worth testing your expressions against the specific library you're targeting.

JSONPath Is Worth Adding to Your Toolkit

The argument for JSONPath isn't that it's magic — it's that it's composable and readable. A well-written JSONPath expression communicates intent at a glance. Nested loops require reading to the end before you understand what's being extracted.

It's also portable: the same expression works in JavaScript, Python, Java, and tools like Postman, AWS CloudFormation, and Kubernetes JSON patches. Learning it once pays off across your entire stack.

What's the most complex JSON query you've had to write? Did you reach for JSONPath, or did you end up with custom traversal logic you later regretted?

Free tools used in this post:

JSONPath Evaluator — test JSONPath expressions against any JSON payload, results highlighted live
JSON Beautifier — format and indent raw JSON for easy reading
JSON Validator — confirm your JSON is well-formed before querying it
JSON Patch — apply RFC 6902 patches to modify JSON structures in place
All tools — client-side, no sign-up, nothing leaves your browser

JSONL Explained: The Line-by-Line Format Powering AI Datasets

Tahmid — Tue, 28 Apr 2026 01:50:11 +0000

You're trying to load a 500,000-record dataset into your script. You reach for JSON — it's universal, readable, everyone knows it. But the moment you call JSON.parse() on a 2 GB file, your process runs out of memory and crashes.

This is the problem JSONL (JSON Lines) was built to solve. And if you're working with AI training data, log pipelines, or any large-scale data processing, understanding JSONL will save you from real production pain.

What Is JSONL?

JSONL (also written .jsonl or called "JSON Lines") is a text format where each line is a self-contained, valid JSON object. There's no wrapping array, no commas between records — just one JSON object per line, separated by newlines.

Here's the key distinction:

Standard JSON array:

[
  {"id": 1, "name": "Alice", "role": "admin"},
  {"id": 2, "name": "Bob", "role": "editor"},
  {"id": 3, "name": "Carol", "role": "viewer"}
]

JSONL equivalent:

{"id": 1, "name": "Alice", "role": "admin"}
{"id": 2, "name": "Bob", "role": "editor"}
{"id": 3, "name": "Carol", "role": "viewer"}

The difference looks small. The impact at scale is enormous.

With a JSON array, the entire file must be parsed into memory before you can read a single record. With JSONL, you can stream the file one line at a time — processing millions of records with constant memory usage.

Processing JSONL Line by Line

Here's the practical difference in Node.js. First, the approach that breaks on large files:

// ❌ Loads the entire file into memory before processing a single record
const data = JSON.parse(fs.readFileSync('users.json', 'utf8'));
data.forEach(record => process(record));

Now the JSONL equivalent, which handles files of any size:

// ✅ Streams one line at a time — constant memory usage
import { createReadStream } from 'fs';
import { createInterface } from 'readline';

const rl = createInterface({
  input: createReadStream('users.jsonl'),
});

rl.on('line', (line) => {
  if (line.trim()) {
    const record = JSON.parse(line);
    process(record);
  }
});

The second approach works equally well on a 1,000-record file and a 50-million-record file. That's the core value of JSONL.

Why AI and LLMs Love JSONL

If you've worked with OpenAI's fine-tuning API, you've already encountered JSONL. The required format for training data is a .jsonl file where each line is a conversation turn:

{"messages": [{"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "What is the capital of France?"}, {"role": "assistant", "content": "Paris."}]}
{"messages": [{"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "How do I reverse a string in Python?"}, {"role": "assistant", "content": "You can use slicing: s[::-1]"}]}

Each line = one training example. You can add or remove examples without touching any other line in the file. You can run wc -l on the file to instantly count your training examples. You can head -n 10 to preview the first 10 records. These are the small ergonomic wins that matter when you're curating thousands of examples.

Log aggregation systems like Elasticsearch, Datadog, and Loki also ingest JSONL natively — each log entry is a self-contained object that can be appended without locking the file.

Working With JSONL Files

When you have a messy JSONL file — maybe it came from an export, maybe lines got mangled in transit — validation can get frustrating fast. Standard JSON validators reject the entire file because, as a whole, it isn't valid JSON.

The JSONL Formatter on JSON Indenter handles this correctly: it validates and formats each line independently, highlights which specific lines have errors, and lets you fix them without losing the rest of the file. No sign-up, nothing leaves your browser.

If you need to inspect a single record in detail, paste it into the JSON Beautifier for a properly indented, readable view — especially handy for deeply nested objects crammed into a single JSONL line.

For production pipelines where you're writing JSONL to disk or streaming it over the wire, run each record through the JSON Minifier first. Stripping whitespace from each record before appending it to your .jsonl file keeps sizes lean and ingestion fast.

For a deeper look at edge cases — empty lines, Unicode handling, NDJSON compatibility — the JSONL Format Explained guide covers the full picture.

When to Use JSONL vs Regular JSON

JSONL wins when:

Your dataset has more than a few thousand records
You need to append records incrementally (logs, event streams, AI training data)
You're feeding data to an LLM fine-tuning job or a RAG pipeline
You want line-level git diffs that are actually readable

Stick with standard JSON when:

The data is a config file or small lookup table
You need deep, document-level structure where the whole object matters
You're calling an API that expects a JSON array in the request body

A Common Gotcha

Empty lines in JSONL files will cause JSON.parse('') to throw a SyntaxError. Always guard against them:

rl.on('line', (line) => {
  if (line.trim() === '') return; // skip blank lines
  const record = JSON.parse(line);
  // ...
});

This bites people constantly with JSONL files exported from tools that append a trailing newline after the last record — which is nearly all of them.

Are you using JSONL in your stack — for logs, datasets, or AI pipelines? And have you run into any tools or patterns that make working with large JSONL files smoother? Drop a note in the comments.

Free tools used in this post:

JSONL Formatter — validates and formats each line in a JSONL file independently
JSON Beautifier — pretty-prints any JSON object with proper indentation
JSON Minifier — strips whitespace from JSON to shrink file sizes
All tools — client-side, no sign-up, nothing leaves your browser

How to Convert JSON to TypeScript Types (Without Writing Them by Hand)

Tahmid — Tue, 28 Apr 2026 01:40:20 +0000

You just got access to a new API. The response comes back — it's a deeply nested JSON object with 40 fields, some optional, some arrays, some nested objects three levels deep. Your team lead says: "We need this typed properly." So you open a new .ts file and start typing interface...

That's an hour of your life you're not getting back — and the types might still be wrong.

Manual JSON-to-TypeScript conversion is one of those tasks that feels like real work but is basically just copying data shapes from one format to another. Here's a better way.

The Problem With Manual Type Writing

Hand-typing TypeScript interfaces from JSON has three common failure modes:

Missing optional fields — APIs often return null or omit fields in edge cases. If you type from a single example response, you'll likely mark optional fields as required.
Wrong primitive types — A field that looks like a number ("count": 42) might occasionally come back as a string ("count": "42") from a legacy backend. You won't catch this until runtime.
It doesn't scale — When the API response changes, you have to re-read and re-type the whole thing manually.

Real Example: Before and After

Say you get this from an API:

{
  "user": {
    "id": 1024,
    "name": "Alice",
    "email": "alice@example.com",
    "roles": ["admin", "editor"],
    "profile": {
      "bio": "Engineer at Acme",
      "avatar_url": "https://example.com/alice.png",
      "joined_at": "2024-01-15T09:30:00Z"
    },
    "settings": {
      "notifications_enabled": true,
      "theme": "dark"
    }
  }
}

If you wrote this by hand, you'd probably produce something like this:

interface Profile {
  bio: string;
  avatar_url: string;
  joined_at: string;
}

interface Settings {
  notifications_enabled: boolean;
  theme: string;
}

interface User {
  id: number;
  name: string;
  email: string;
  roles: string[];
  profile: Profile;
  settings: Settings;
}

interface ApiResponse {
  user: User;
}

That works — but you typed it from one example. Real-world responses can have bio: null, or avatar_url might be absent entirely. You'd discover those gaps at runtime, not at compile time.

Using the JSON to TypeScript converter, you paste the JSON and get properly structured interfaces in seconds. It handles nested objects, arrays, and can mark fields as optional — which is a much safer default for API responses.

Going Further: Runtime Validation With Zod

TypeScript types are compile-time only. They don't protect you at runtime — and if you're fetching from an external API, that's exactly when things go wrong.

A common pattern is pairing your TypeScript interfaces with a Zod schema so you can validate actual API responses at runtime:

import { z } from "zod";

const ProfileSchema = z.object({
  bio: z.string().nullable(),
  avatar_url: z.string().optional(),
  joined_at: z.string(),
});

const UserSchema = z.object({
  id: z.number(),
  name: z.string(),
  email: z.string(),
  roles: z.array(z.string()),
  profile: ProfileSchema,
  settings: z.object({
    notifications_enabled: z.boolean(),
    theme: z.string(),
  }),
});

// Runtime check — throws if the shape doesn't match
const response = await fetch("/api/user/1024");
const data = UserSchema.parse(await response.json());
// Now `data` is fully typed AND validated

You can generate this Zod schema automatically from any JSON using the JSON to Zod tool. The jsonindenter.com blog also has a deeper post on building Zod schemas from JSON for TypeScript projects that covers validation edge cases worth reading.

One More Step: Validate Before You Convert

If the JSON you're working with is malformed — missing quotes, trailing commas, comments copied from a config file — the converter will fail silently or produce wrong output. Run your JSON through a JSON validator first. It highlights the exact line with the problem so you fix it before conversion.

The full workflow looks like this:

Paste the raw JSON from the API response or config file
Validate it to catch any syntax issues
Convert to TypeScript interfaces (and optionally a Zod schema)
Drop the generated types into your codebase

This is especially useful when onboarding a new third-party API or when a backend teammate sends you a sample payload in Slack and you need types in under 60 seconds.

What Auto-Generation Can't Do (Yet)

Generated types have a ceiling. The tools give you the shape of your data, but they can't infer:

Semantic constraints — a status field might only accept "active" | "inactive" but the converter will type it as string
Cross-field relationships — if is_verified being true implies verified_at is non-null, you'll need to express that manually with a discriminated union
Generic patterns — paginated responses where the same wrapper type repeats across endpoints

For those cases, treat auto-generated types as a starting point, not a final answer. But for the vast majority of everyday API work, generation gets you 80% of the way there in seconds rather than spending 30 minutes typing interfaces that might still contain mistakes.

What's the most tedious JSON-to-types conversion you've done by hand? Did anything break when the API response changed later? Drop it in the comments — I'd genuinely like to know how others handle this.

Free tools used in this post:

JSON to TypeScript — paste JSON, get TypeScript interfaces instantly
JSON to Zod — generate Zod validation schemas from any JSON structure
JSON Validator — catch syntax errors before converting
All tools — client-side, no sign-up, nothing leaves your browser

How to Minify JSON and Shrink Your API Payloads in Seconds

Tahmid — Mon, 27 Apr 2026 23:21:33 +0000

You're debugging a slow API and you open the response in your browser's network tab. The payload is 620 KB. You paste it into a text editor and immediately spot the problem: every key is quoted, every value is neatly indented, and there are blank lines between sections. Your beautiful, readable JSON is costing you hundreds of milliseconds per request.

Whitespace is free when you're reading JSON. It's not free when you're sending it across a network a thousand times a day.

What minification actually does

JSON minification strips out every character that doesn't change what the data means: spaces, newline characters, and indentation. The JSON spec doesn't require any of it — a parser doesn't care whether your keys are separated by \n or nothing at all.

Here's the same config object, formatted vs. minified:

Before (formatted):

{
  "user": {
    "id": 1042,
    "name": "Priya Kapoor",
    "role": "admin",
    "preferences": {
      "theme": "dark",
      "notifications": true,
      "language": "en-US"
    }
  },
  "session": {
    "token": "eyJhbGciOiJIUzI1NiJ9",
    "expires_at": "2026-05-01T00:00:00Z"
  }
}

After (minified):

{"user":{"id":1042,"name":"Priya Kapoor","role":"admin","preferences":{"theme":"dark","notifications":true,"language":"en-US"}},"session":{"token":"eyJhbGciOiJIUzI1NiJ9","expires_at":"2026-05-01T00:00:00Z"}}

Same data. 43% fewer characters. For a small config object the difference is trivial — but when you're serialising paginated API responses, search results, or analytics events, it adds up fast.

Three ways to minify JSON

In the browser (zero setup)

If you're working with a one-off payload — say, you grabbed a response from Postman and need to paste it into a config file — the fastest path is JSON Minifier on jsonindenter.com. Paste, click, copy. Everything runs client-side so nothing leaves your browser, which matters when the JSON contains credentials or PII.

In Python

Python's json module handles this with a single argument:

import json

# Load from a file or string
with open("response.json") as f:
    data = json.load(f)

# Minify by setting separators and no indentation
minified = json.dumps(data, separators=(",", ":"))
print(minified)

separators=(",", ":") tells the encoder to drop the space after each comma and colon. That's the entire trick. For bulk processing, wrap this in a script that walks a directory of JSON files and overwrites each one with its minified version.

In Node.js / JavaScript

const fs = require("fs");

const raw = fs.readFileSync("data.json", "utf8");
const minified = JSON.stringify(JSON.parse(raw));

fs.writeFileSync("data.min.json", minified);
console.log(`Original: ${raw.length} chars → Minified: ${minified.length} chars`);

JSON.stringify without a space argument produces minified output by default. If your current code passes JSON.stringify(data, null, 2) for pretty-printing, removing that third argument is all you need to do in production.

When minification matters most

Minification pays off most in these situations:

Static JSON files served from a CDN — config files, feature-flag payloads, i18n translation bundles. These are downloaded on every cold start; every kilobyte counts.
High-frequency API endpoints — if an endpoint is hit thousands of times per minute, even a 10 KB saving compounds quickly into meaningful bandwidth cost reduction.
Mobile clients on flaky connections — smaller payloads parse faster and fail less often on spotty networks.
Logging pipelines — if you're shipping structured JSON logs to a log aggregator, minifying before transmission can cut your ingestion bill noticeably.

Where it doesn't matter: internal service-to-service calls on a fast private network, or any place where debugging the raw wire format outweighs the bandwidth saving.

Minify in production, read in development

The natural workflow is to keep formatted JSON in your version control and your editor (it's much easier to review diffs and catch mistakes), and minify only at build time or at the serialisation layer in production.

If you ever need to go the other direction — you've received a minified blob and need to read it — JSON Indenter formats it back into something human-readable instantly. Paste the minified string and it comes out with proper indentation and syntax highlighting. Useful when you're hunting a bug in a production response.

For tips on validating JSON before you minify it (invalid JSON will cause JSON.parse to throw at runtime), see Why Your JSON Keeps Breaking (And How to Fix It Fast) — it covers the most common syntax mistakes that slip through code review.

What's your preferred approach — minifying at the application layer, at the CDN edge, or somewhere else? And have you ever hit a production bug that traced back to a minification step mangling something unexpectedly?

Free tools used in this post:

JSON Minifier — strips whitespace from any JSON payload instantly, runs entirely in your browser
JSON Indenter — formats minified JSON back into readable, indented output
All tools — client-side, no sign-up, nothing leaves your browser

Why Your JSON Keeps Breaking (And How to Fix It Fast)

Tahmid — Sat, 18 Apr 2026 21:48:08 +0000

You paste a JSON config into your app and hit SyntaxError: Unexpected token. You scan 60 lines of curly braces, counting quotes by eye. Five minutes later you spot it — a trailing comma on line 47. Sound familiar?

JSON is ruthlessly strict. No trailing commas. No comments. No single quotes. No unquoted keys. Even one character out of place produces a completely opaque error message that points you to the wrong line half the time. This post covers the four JSON mistakes that cause 90% of parse failures, how to spot them instantly, and how to stop wasting time on them.

The Four Most Common JSON Errors

1. Trailing Commas

This is the most frequent offender, especially if your JSON was hand-written or copied from a JavaScript object literal.

Broken:

{
  "name": "Alice",
  "role": "admin",
  "active": true,
}

Fixed:

{
  "name": "Alice",
  "role": "admin",
  "active": true
}

The trailing comma after true is valid JavaScript but illegal JSON. Most parsers point you to the closing brace, not the offending comma, which sends you hunting in the wrong direction.

2. Single Quotes Instead of Double Quotes

Developers who spend most of their time in JavaScript or Python often reach for single quotes out of habit.

Broken:

{
  'username': 'bob',
  'permissions': ['read', 'write']
}

Fixed:

{
  "username": "bob",
  "permissions": ["read", "write"]
}

The JSON specification (RFC 8259) is explicit: strings must use double quotes. Single quotes are not valid, period.

3. Comments Embedded in JSON

If you copied a config from documentation or a README, it may include comments added for human clarity. JSON does not support comments.

Broken:

{
  // database settings
  "host": "localhost",
  "port": 5432,  /* default postgres port */
  "database": "myapp"
}

Fixed:

{
  "host": "localhost",
  "port": 5432,
  "database": "myapp"
}

Strip every // line comment and every /* */ block comment before parsing. If you need to annotate your configs, consider YAML or TOML — or adopt a _comment key as a convention.

4. JavaScript-Only Values

undefined, NaN, and Infinity are valid JavaScript but completely foreign to JSON. Only null, true, false, numbers, strings, arrays, and objects are allowed.

Broken:

{
  "count": NaN,
  "result": undefined,
  "ratio": Infinity
}

Fixed:

{
  "count": 0,
  "result": null,
  "ratio": null
}

These typically appear when serializing JavaScript objects that contain these special values — a common trap when using JSON.stringify() without a replacer function.

Stop Hunting for Errors by Eye

Reading JSON manually for syntax errors is a poor use of your attention. Paste your broken JSON into the JSON Formatter & Validator at jsonindenter.com and it will immediately highlight exactly which line is wrong and why. It also re-indents the output so that nested structures become readable at a glance — a lifesaver when someone hands you a 2KB single-line blob.

The validator catches all four of the errors described above and gives you a plain-English error message rather than the cryptic column-number output your runtime throws.

Comparing Two JSON Responses

Another common scenario: you have two versions of a JSON response — one from staging, one from production — and something is different but you can't tell what. Diffing them by eye across two editor tabs is tedious and error-prone.

The JSON Diff tool does a structural comparison of two JSON documents and highlights exactly which keys were added, removed, or changed in value. Because it understands JSON structure, it doesn't get confused by whitespace changes or key reordering — it shows you only what actually changed semantically.

Minifying for Production

Once your JSON is clean and validated, you may want to strip all whitespace before embedding it in a build artifact or sending it over the wire. The JSON Minifier removes all unnecessary whitespace in one click. For a 500-line formatted config file, the minified output is typically 3–5× smaller by byte count — a meaningful difference in payload-sensitive contexts like mobile APIs or edge functions.

A Practical Debugging Workflow

When JSON breaks in a project, this three-step process gets me to a fix in under two minutes:

Paste into the formatter — it shows the exact error location and corrects indentation so the structure is visible
Fix the flagged issue and validate again until the document is clean
If the JSON parses successfully but behavior is still wrong, use the diff tool to compare against the last known-good version line by line

This replaces what used to be ten minutes of manual scanning and guessing.

The Bigger Picture

Most JSON headaches come from the same handful of mistakes, and almost all of them come from editing JSON by hand or copying it from contexts that allow looser syntax — JavaScript objects, Python dicts, config files with comments. The fix isn't memorizing the spec; it's building a habit of running JSON through a validator before it ever reaches your parser.

What's your most painful "I spent an hour on a trailing comma" story? Drop it in the comments — I know I'm not the only one who's been there.

Free tools used in this post:

JSON Formatter & Validator — paste broken JSON and get instant error highlighting with clean re-indentation
JSON Diff — structural comparison of two JSON documents, shows exactly what changed semantically
JSON Minifier — strips all whitespace from JSON for smaller payloads
All tools — client-side, no sign-up, nothing leaves your browser

How to Compare Two JSON Objects and Spot the Differences Instantly

Tahmid — Sat, 18 Apr 2026 21:47:55 +0000

You're two hours into debugging a production issue. Your API contract says the response should look like this:

{
  "user": {
    "id": 42,
    "name": "Alice",
    "role": "admin",
    "active": true
  },
  "permissions": ["read", "write", "delete"]
}

But something downstream is breaking. You log the actual response and squint at it. It looks the same. Roughly. But your authorization middleware just denied an admin user.

That's when you notice: "role" is missing. Or it became "roles". Or "active" is now the string "true" instead of a boolean. Bugs like this are trivially small and brutally hard to spot in a wall of JSON text — especially when the payload is minified or poorly indented.

Here's a practical workflow for comparing two JSON objects and catching differences before they catch you.

Step 1: Format both objects identically

Comparing minified JSON visually is a waste of time. If your two blobs have different indentation, trailing whitespace, or inconsistent key ordering, even a side-by-side diff tool will light up with false positives.

Before anything else, run both objects through a formatter. Paste each one into JSON Indenter and make sure you're comparing apples to apples: same indentation style, same structure, same readability.

Before (minified):

{"user":{"id":42,"name":"Alice","role":"admin","active":true},"permissions":["read","write","delete"]}

After (formatted):

{
  "user": {
    "id": 42,
    "name": "Alice",
    "role": "admin",
    "active": true
  },
  "permissions": ["read", "write", "delete"]
}

Now you can actually read it. This single step eliminates a whole class of "differences" that are really just formatting noise.

Step 2: Validate before you compare

If either object has a syntax error, your diff will give you nonsense. A stray trailing comma, an unquoted key, or a missing bracket will corrupt the comparison before it starts.

Run both objects through the JSON Validator before proceeding. It surfaces syntax errors with exact line numbers, so you fix the structure first and compare content second.

This matters more than you'd think. Many JSON objects in the wild come from sources that produce technically invalid JSON — config files with comments, legacy APIs with trailing commas, log entries with prepended timestamps. Validate early.

Step 3: Compare programmatically when you need precision

For automated tests or CI pipelines, visual comparison doesn't scale. Here's where programmatic diffing becomes essential.

The naive approach — and why it fails:

const a = { user: { id: 42, name: "Alice" } };
const b = { user: { name: "Alice", id: 42 } };

console.log(JSON.stringify(a) === JSON.stringify(b));
// false — key order matters for string comparison, not for JSON semantics

JSON.stringify is order-sensitive. Two objects that are semantically identical can produce different strings if their keys were inserted in a different order.

A better approach — recursive diff with specific output:

function jsonDiff(a, b, path = "") {
  const diffs = [];
  const allKeys = new Set([...Object.keys(a), ...Object.keys(b)]);

  for (const key of allKeys) {
    const fullPath = path ? `${path}.${key}` : key;
    if (!(key in a)) {
      diffs.push(`ADDED: ${fullPath} = ${JSON.stringify(b[key])}`);
    } else if (!(key in b)) {
      diffs.push(`REMOVED: ${fullPath}`);
    } else if (typeof a[key] === "object" && a[key] !== null
               && typeof b[key] === "object" && b[key] !== null) {
      diffs.push(...jsonDiff(a[key], b[key], fullPath));
    } else if (a[key] !== b[key]) {
      diffs.push(`CHANGED: ${fullPath}: ${JSON.stringify(a[key])} → ${JSON.stringify(b[key])}`);
    }
  }

  return diffs;
}

const result = jsonDiff(
  { user: { id: 42, name: "Alice", role: "admin" }, active: true },
  { user: { id: 42, name: "Alice" }, active: "true" }
);

console.log(result);
// ["REMOVED: user.role", "CHANGED: active: true → \"true\""]

This is far more useful than a raw boolean — you get the exact path and the exact values that changed.

Where types silently bite you

The most dangerous JSON diffs aren't missing keys — they're type changes. A value going from true (boolean) to "true" (string) looks identical in most log outputs but behaves completely differently in application logic.

Your comparison logic needs to be explicit about types. In the function above, a[key] !== b[key] catches this because JavaScript's strict equality distinguishes true from "true". In Python, watch out for integers and floats comparing as equal (1 == 1.0), which can mask precision changes that matter to downstream typed systems.

For a deeper look at the syntax issues and type mismatches that show up most often in real payloads, the 5 Common JSON Errors post on JSON Indenter's blog is worth a read — it covers the patterns that trip up developers most reliably.

When to reach for a library

For production use, libraries like deep-diff (Node.js) or deepdiff (Python) go further: they handle arrays intelligently, track moved elements, and give you structured change records you can iterate over. But for day-to-day debugging — the "why is this response different from yesterday?" question you face a dozen times a month — formatting both payloads consistently, validating them, and running a simple recursive diff gets you to the answer in under two minutes.

What's your go-to approach when two API responses look identical but aren't? Have you ever been burned by a boolean quietly becoming a string, or a key silently renamed in a schema update? Drop your war stories in the comments — I'd love to hear how others handle this.

Free tools used in this post:

JSON Formatter & Validator — instantly formats and beautifies JSON in your browser, client-side
JSON Validator Pro — lint and validate JSON with exact line-number error reporting
All tools — client-side, no sign-up, nothing leaves your browser

How to structure JSON for LLMs (and stop wasting tokens)

Tahmid — Sat, 18 Apr 2026 19:15:15 +0000

Most developers treat JSON as an afterthought when building LLM-powered apps. They dump raw API responses into prompts and wonder why the model hallucinates, misreads fields, or burns through tokens.

JSON structure is a first-class concern in AI engineering. Here's how to get it right.

The problem: LLMs don't read JSON like humans do

When you paste this into a prompt:

{"user":{"id":1,"name":"Alice","preferences":{"theme":"dark","notifications":true,"language":"en"}}}

The model tokenizes it character by character. Every {, ", :, and , is a token. Deeply nested structures force the model to maintain more working context just to understand the shape of the data — before it even processes the values.

The result: more tokens consumed, more room for misinterpretation, higher API costs.

Rule 1: Flatten before you prompt

Nested JSON is great for APIs. It's bad for prompts.

Before:

{
  "user": {
    "profile": {
      "name": "Alice",
      "age": 28
    }
  }
}

After (flattened):

{
  "user_name": "Alice",
  "user_age": 28
}

One level deep is almost always enough for LLM context. If the model needs to reason about relationships, describe them in natural language alongside the data — don't encode them in nesting.

Rule 2: Strip fields the model doesn't need

Every field in your JSON costs tokens. If the model doesn't need created_at, updated_at, internal_id, or _metadata — remove them before building the prompt.

const { created_at, updated_at, _metadata, ...relevant } = apiResponse;
const prompt = `Here is the user data: ${JSON.stringify(relevant)}`;

This alone can cut token usage by 20–40% on typical API responses.

Rule 3: Use TOON for large payloads

If you're passing payloads larger than ~500 tokens, consider TOON (Token-Oriented Object Notation). It's a compact alternative to JSON that strips redundant syntax while preserving structure.

JSON:

[
  {"name": "Alice", "role": "admin"},
  {"name": "Bob", "role": "editor"}
]

TOON:

name|role
Alice|admin
Bob|editor

Token reduction: 30–60% on typical datasets. The model reads it correctly because the structure is still unambiguous — just more compact.

Try it on your own payloads with the JSON to TOON converter. There's also a TOON to JSON converter for decoding the model's response back.

Rule 4: Use JSON Schema to enforce structured outputs

LLMs can return JSON — but without constraints, they hallucinate keys, change types, and add fields you didn't ask for.

The fix: define a schema and include it in your system prompt.

{
  "type": "object",
  "properties": {
    "sentiment": { "type": "string", "enum": ["positive", "negative", "neutral"] },
    "confidence": { "type": "number", "minimum": 0, "maximum": 1 },
    "summary": { "type": "string", "maxLength": 200 }
  },
  "required": ["sentiment", "confidence", "summary"]
}

Tell the model: "Respond only with a JSON object matching this schema. No explanation, no markdown."

Then validate the output with a JSON Schema validator before trusting it. This is especially critical in agentic workflows where one bad output poisons downstream steps. You can generate a schema automatically from any sample payload using the JSON Schema generator — useful as a starting point you can then tighten up.

Rule 5: Use Pydantic or Zod to validate at the boundary

Never trust raw LLM JSON output in production. Parse and validate it immediately.

Python (FastAPI / AI agents):

from pydantic import BaseModel

class SentimentResult(BaseModel):
    sentiment: str
    confidence: float
    summary: str

result = SentimentResult.model_validate_json(llm_output)

TypeScript (Next.js / tRPC):

import { z } from 'zod';

const SentimentResult = z.object({
  sentiment: z.enum(['positive', 'negative', 'neutral']),
  confidence: z.number().min(0).max(1),
  summary: z.string().max(200),
});

const result = SentimentResult.parse(JSON.parse(llmOutput));

Writing these by hand from a large JSON payload is tedious. The JSON to Pydantic and JSON to Zod generators handle it instantly — paste your payload, get the model.

Rule 6: Use TypeScript interfaces when working with typed LLM outputs

If you're building in TypeScript, generating interfaces from your JSON response shapes saves time and prevents drift between what the LLM returns and what your code expects.

// Generated from your actual LLM response shape
interface SentimentResponse {
  sentiment: 'positive' | 'negative' | 'neutral';
  confidence: number;
  summary: string;
}

The JSON to TypeScript converter generates these from any payload — useful when you're iterating quickly on prompt outputs and want the type system to catch regressions.

The full checklist

Before passing JSON to an LLM:

Flatten nested structures to one level where possible
Strip fields irrelevant to the task
Use TOON for payloads > 500 tokens
Define a JSON Schema for expected output
Validate output with Pydantic or Zod before use
Use TypeScript interfaces to catch output shape regressions

These aren't micro-optimisations. On high-volume AI apps, they compound into significant cost and reliability improvements.

What's your current approach to JSON in LLM workflows? Drop it in the comments — I'm curious how others handle this.

Free tools used in this post:

JSON to TOON — compress JSON for LLM context
TOON to JSON — decode TOON back to JSON
JSON Schema Generator — generate schemas from sample payloads
JSON to Pydantic — instant Python models
JSON to Zod — instant TypeScript validation schemas
JSON to TypeScript — generate interfaces from any payload
All tools — client-side, no sign-up, nothing leaves your browser

JWT security mistakes that will get you breached

Tahmid — Sat, 18 Apr 2026 19:05:55 +0000

JWTs are everywhere. Auth tokens, API keys, session management — if you're building web apps, you're almost certainly using them. They're also one of the most commonly misconfigured pieces of security infrastructure in production systems.

Here are the mistakes I see repeatedly, and exactly how to fix them.

Quick recap: what a JWT actually is

A JWT has three parts separated by dots:

header.payload.signature

Header — algorithm used to sign the token (HS256, RS256, etc.)
Payload — the claims (user ID, roles, expiry, etc.)
Signature — cryptographic proof the token hasn't been tampered with The payload is base64-encoded, not encrypted. Anyone who intercepts your token can read everything in it. This matters more than most developers realise.

If you want to see this in action, paste any token into a JWT decoder and read the payload in plain text — no tools, no secret needed.

Mistake 1: Using the `none` algorithm

This is the most catastrophic JWT vulnerability. Some libraries accept a token signed with alg: none — meaning no signature at all.

An attacker can craft a token like this:

// Header (base64 decoded)
{ "alg": "none", "typ": "JWT" }

// Payload (base64 decoded)
{ "sub": "1234", "role": "admin" }

If your server accepts it, the attacker just gave themselves admin access with no credentials.

Fix: Explicitly allowlist the algorithms your server accepts. Never allow none.

// Node.js / jsonwebtoken
jwt.verify(token, secret, { algorithms: ['HS256'] });

Mistake 2: Weak or hardcoded secrets

HS256 is a symmetric algorithm — the same secret signs and verifies tokens. If your secret is weak or leaked, every token ever issued is compromised.

Common offenders:

secret
password
jwt_secret
mysecretkey
your-256-bit-secret   ← literally from the JWT.io example

Fix: Generate secrets with sufficient entropy and store them in environment variables, never in code.

# Generate a strong secret
node -e "console.log(require('crypto').randomBytes(64).toString('hex'))"

For production systems with multiple services, prefer RS256 (asymmetric) — the private key signs, the public key verifies. A compromised verification service can't forge tokens. You can test tokens signed with different algorithms using the JWT encoder to understand exactly what gets embedded.

Mistake 3: Storing JWTs in localStorage

localStorage is accessible to any JavaScript running on your page. A single XSS vulnerability — in your code, a dependency, or a third-party script — exposes every stored token.

Fix: Store JWTs in HttpOnly cookies. They're invisible to JavaScript entirely.

res.cookie('token', jwt, {
  httpOnly: true,    // not accessible via JS
  secure: true,      // HTTPS only
  sameSite: 'strict' // CSRF protection
});

Yes, this requires handling CSRF. That's a better problem to have than XSS token theft.

Mistake 4: No expiry — or expiry that's too long

A JWT with no exp claim is valid forever. If it's leaked, stolen, or the user's account is compromised, you have no way to invalidate it short of rotating your signing secret (which invalidates every token).

Fix: Set short expiry for access tokens, longer for refresh tokens.

const accessToken = jwt.sign(payload, secret, { expiresIn: '15m' });
const refreshToken = jwt.sign(payload, secret, { expiresIn: '7d' });

15 minutes for access tokens is a common production standard. Refresh tokens should be rotated on use and stored server-side so they can be revoked.

Mistake 5: Putting sensitive data in the payload

The payload is not encrypted. It's trivially decoded by anyone with the token:

echo "eyJ1c2VyIjoiYWxpY2UiLCJwYXNzd29yZCI6InNlY3JldCJ9" | base64 -d
# {"user":"alice","password":"secret"}

I've seen production tokens containing passwords, full PII, credit card fragments, and internal system details. All readable by anyone who intercepts the token. Try it yourself — paste that string into a JWT decoder and see exactly what's exposed.

Fix: Put only the minimum identifying information in the payload.

{
  "sub": "user_abc123",
  "role": "admin",
  "exp": 1735689600
}

Look up everything else server-side using the sub claim. If you need the payload encrypted, use JWE (JSON Web Encryption) — a different standard entirely.

Mistake 6: Not validating claims server-side

Libraries verify the signature automatically — but claim validation is on you.

// Bad — only verifies signature
const decoded = jwt.verify(token, secret);

// Good — verify signature AND validate claims
const decoded = jwt.verify(token, secret, { algorithms: ['HS256'] });

if (decoded.exp < Date.now() / 1000) throw new Error('Token expired');
if (decoded.iss !== 'https://yourapp.com') throw new Error('Invalid issuer');
if (decoded.aud !== 'your-api') throw new Error('Invalid audience');

Always validate exp, iss (issuer), and aud (audience) explicitly — especially if tokens from multiple issuers could reach your API.

Mistake 7: No token revocation strategy

JWTs are stateless by design — once issued, they're valid until expiry. But what happens when:

A user logs out
An account is compromised
A user's role changes mid-session If you're relying purely on token expiry, a stolen 15-minute token is valid for up to 15 minutes after the breach is detected.

Fix: Maintain a server-side revocation list (denylist) for sensitive operations.

// On logout
await redis.set(`revoked:${jti}`, '1', 'EX', 900); // expire after token TTL

// On verify
const isRevoked = await redis.get(`revoked:${decoded.jti}`);
if (isRevoked) throw new Error('Token revoked');

Add a jti (JWT ID) claim — a unique identifier per token — so you can target specific tokens for revocation without rotating your secret.

The JWT security checklist

Explicitly allowlist algorithms — never allow none
Use strong, randomly generated secrets (64+ bytes)
Prefer RS256 for multi-service architectures
Store tokens in HttpOnly cookies, not localStorage
Set short expiry on access tokens (15 minutes)
Put only non-sensitive identifiers in the payload
Validate exp, iss, and aud claims explicitly

- Implement token revocation with a `jti` denylist

JWTs are a solid auth primitive when implemented correctly. The problems almost always come from default configurations and library trust — not the spec itself.

What JWT issue have you encountered in production? Drop it in the comments.

Free tools used in this post:

JWT Decoder — inspect any token without a secret
JWT Encoder — generate and sign JWTs for testing
All JSON & JWT tools — everything runs client-side, nothing leaves your browser

5 JSON tricks most developers don't use

Tahmid — Sat, 18 Apr 2026 18:01:11 +0000

JSON is everywhere, but most developers only use JSON.parse() and JSON.stringify(). Here are a few tricks worth knowing.

1. Pretty-print in one line

console.log(JSON.stringify(data, null, 2));

The third argument is your indent size. Instant readability.

2. Filter keys on stringify

JSON.stringify(user, ['name', 'email'], 2);

Pass an array of keys to only include those fields. Great for logging without exposing sensitive data.

3. JSONPath for deep queries

Instead of chaining .map() and .filter(), JSONPath lets you query nested JSON like a database:

$.users[?(@.age > 30)].name

4. Auto-repair broken JSON

LLMs often return slightly malformed JSON — trailing commas, single quotes, missing brackets. Instead of debugging it manually, a repair function can fix most common issues automatically.

5. Reduce LLM token usage with compact formats

If you're passing large JSON payloads as context to GPT or Claude, consider stripping whitespace at minimum. Better yet, look into TOON (Token-Oriented Object Notation) — a compact alternative that cuts token count by 30–60% without losing structure.

I built jsonindenter.com as a free client-side toolkit that covers all of the above — JSONPath tester, JSON repair, TOON converter, Zod/Pydantic generators, JWT tools, and more. No sign-up, no ads, your data never leaves your browser.

What JSON tricks do you swear by? Drop them in the comments 👇

DEV Community: Tahmid

How to Convert JSON to YAML (and Back) Without Writing a Single Line of Code

Why JSON and YAML Keep Colliding

The Conversion Is Mechanical — But Still Fiddly

Converting in the Browser: The Fast Path

A Real-World Example: Kubernetes ConfigMap

Going the Other Way: YAML Back to JSON

When to Write the Conversion in Code

Further Reading

What Format Mismatch Do You Hit Most?

How to Query Nested JSON with JSONPath (Without Writing Loops)

The Basics: What JSONPath Looks Like

Filtering: The Real Power

Recursive Descent: Finding a Key Anywhere in the Tree

A Practical Workflow for Real API Responses

Quick Reference: Syntax That Covers 80% of Cases

When JSONPath Is the Wrong Tool

JSONPath Is Worth Adding to Your Toolkit

JSONL Explained: The Line-by-Line Format Powering AI Datasets

What Is JSONL?

Processing JSONL Line by Line

Why AI and LLMs Love JSONL

Working With JSONL Files

When to Use JSONL vs Regular JSON

A Common Gotcha

How to Convert JSON to TypeScript Types (Without Writing Them by Hand)

The Problem With Manual Type Writing

Real Example: Before and After

Going Further: Runtime Validation With Zod

One More Step: Validate Before You Convert

What Auto-Generation Can't Do (Yet)

How to Minify JSON and Shrink Your API Payloads in Seconds

What minification actually does

Three ways to minify JSON

When minification matters most

Minify in production, read in development

Why Your JSON Keeps Breaking (And How to Fix It Fast)

The Four Most Common JSON Errors

1. Trailing Commas

2. Single Quotes Instead of Double Quotes

3. Comments Embedded in JSON

4. JavaScript-Only Values

Stop Hunting for Errors by Eye

Comparing Two JSON Responses

Minifying for Production

A Practical Debugging Workflow

The Bigger Picture

How to Compare Two JSON Objects and Spot the Differences Instantly

Step 1: Format both objects identically

Step 2: Validate before you compare

Step 3: Compare programmatically when you need precision

Where types silently bite you

When to reach for a library

How to structure JSON for LLMs (and stop wasting tokens)

The problem: LLMs don't read JSON like humans do

Rule 1: Flatten before you prompt

Rule 2: Strip fields the model doesn't need

Rule 3: Use TOON for large payloads

Rule 4: Use JSON Schema to enforce structured outputs

Rule 5: Use Pydantic or Zod to validate at the boundary

Rule 6: Use TypeScript interfaces when working with typed LLM outputs

The full checklist

JWT security mistakes that will get you breached

Quick recap: what a JWT actually is

Mistake 1: Using the none algorithm

Mistake 2: Weak or hardcoded secrets

Mistake 3: Storing JWTs in localStorage

Mistake 4: No expiry — or expiry that's too long

Mistake 5: Putting sensitive data in the payload

Mistake 6: Not validating claims server-side

Mistake 7: No token revocation strategy

The JWT security checklist

- Implement token revocation with a jti denylist

5 JSON tricks most developers don't use

1. Pretty-print in one line

2. Filter keys on stringify

3. JSONPath for deep queries

4. Auto-repair broken JSON

5. Reduce LLM token usage with compact formats

Mistake 1: Using the `none` algorithm

- Implement token revocation with a `jti` denylist