DEV Community: Deepak Kumar

JSONPath — How to Query and Filter JSON Data

Deepak Kumar — Mon, 24 Aug 2026 07:32:33 +0000

JSONPath is a query language for JSON, providing the same kind of document-navigation power that XPath gives XML developers. Instead of writing nested loops or chained property accesses, you write a compact expression that pinpoints exactly the data you need — whether it lives three levels deep or is scattered across a hundred-element array.

What Is JSONPath and Why Does It Matter?

Stefan Goessner introduced JSONPath in 2007 as a direct analog to XPath 1.0 for XML. Just as XPath lets you write //book[@price<10] to pluck cheap books out of an XML document tree, JSONPath lets you write $.store.book[?(@.price < 10)] to do the same against a JSON structure.

The practical value is highest when working with API responses you don't fully control. Rather than parsing the entire payload and walking the object graph yourself, you hand a JSONPath expression to a library and get back exactly the nodes you care about. This approach is used by REST-testing frameworks like REST Assured in Java, by AWS's query language JMESPath in the AWS CLI, and by the widely used jq command-line tool (which has its own syntax but borrows heavily from the same ideas).

The Root Operator and Basic Navigation

Every JSONPath expression starts with $, representing the root of the document. From there you navigate using dot notation or bracket notation.

$.store.book.title

This reads as: "start at root, enter store, then book, then title." Bracket notation is required when a key contains a hyphen, space, or starts with a digit:

$['store']['book']['title']
$['content-type']

Sample document used throughout this article:

{
  "store": {
    "book": [
      { "title": "Sayings of the Century", "author": "Nigel Rees",     "price": 8.95  },
      { "title": "Sword of Honour",        "author": "Evelyn Waugh",   "price": 12.99 },
      { "title": "Moby Dick",              "author": "Herman Melville","price": 8.99  },
      { "title": "The Lord of the Rings",  "author": "J.R.R. Tolkien", "price": 22.99 }
    ],
    "bicycle": { "color": "red", "price": 19.95 }
  }
}

$.store.bicycle.color returns "red". $.store.book[0].title returns "Sayings of the Century".

Wildcards and Recursive Descent

The wildcard * matches all properties or elements at the current level:

$.store.book[*].author
// ["Nigel Rees", "Evelyn Waugh", "Herman Melville", "J.R.R. Tolkien"]

The recursive descent operator .. searches at any depth, not just the current level:

$..author

This finds every author field anywhere in the document tree, regardless of nesting depth — invaluable when you don't know the exact structure of a deeply nested API response but do know the key name. It can also be combined with a wildcard or index, e.g. $..[0] returns the first element of every array found anywhere in the document.

Array Slicing and Index Access

JSONPath supports Python-style array slicing:

$.store.book[0]      /* first book */
$.store.book[-1]     /* last book (negative index) */
$.store.book[0,2]    /* first and third books (union) */
$.store.book[0:2]    /* first two books (slice, exclusive end) */
$.store.book[1:3]    /* second and third books */
$.store.book[*]      /* all books */

The slice [start:end] follows Python convention — start is inclusive, end is exclusive. Negative indices count from the end, so [-1] always gives the last element regardless of array length — cleaner than computing array.length - 1 in application code.

Filter Expressions

Filter expressions select array elements matching a condition, using [?( expression )] where @ refers to the current element:

/* books costing less than $10 */
$.store.book[?(@.price < 10)]

/* books that have an isbn property */
$.store.book[?(@.isbn)]

/* books priced between $8 and $13 */
$.store.book[?(@.price >= 8 && @.price <= 13)]

Filters are evaluated per element — @ is bound to each array element in turn, and only elements where the expression is true are included. The first example above returns the two books priced at $8.95 and $8.99.

A more real-world example — extracting users whose email domain is gmail.com:

$.users[?(@.email =~ /.*@gmail\.com$/)]

Note that regex support (=~) is available in some implementations (notably the Jayway Java library) but isn't part of the original Goessner spec — check your library's docs for which operators are supported.

Built-in Functions

RFC 9535 (the JSONPath 2.0 spec, published 2024) formalizes a set of built-in functions:

$.store.book.length()          /* number of books */
$.store.keys()                 /* all keys of the store object */
$.store.book[*].price.min()    /* minimum price across all books */
$.store.book[*].price.max()    /* maximum price */
$.users[?( match(@.name, "A.*") )]   /* string matching */

length() is especially useful inside filters: $.users[?( length(@.tags) > 2 )] returns only users with more than two tags. RFC 9535's match() and search() functions use I-Regexp patterns — match() requires a full-string match, search() succeeds if the pattern matches anywhere in the string.

Practical Examples

Extract all email addresses from a user list:

{
  "users": [
    { "id": 1, "name": "Alice", "email": "alice@example.com" },
    { "id": 2, "name": "Bob",   "email": "bob@example.com"   },
    { "id": 3, "name": "Carol", "email": "carol@example.com" }
  ]
}

$.users[*].email
// ["alice@example.com", "bob@example.com", "carol@example.com"]

Find all books under $15:

$.store.book[?(@.price < 15)]
// Returns the three objects priced 8.95, 12.99, and 8.99

Get the last element when array length is unknown:

$.store.book[-1]
// Returns the Lord of the Rings object

Where JSONPath Is Used in Practice

REST Assured (Java) ships with built-in JSONPath support for API test assertions:

given().when().get("/books").then().body("store.book[0].title", equalTo("Sayings of the Century"));

JMESPath is AWS's answer to JSONPath, used by the AWS CLI's --query flag. The syntax differs (no $ root), but the concept is identical:

aws ec2 describe-instances --query "Reservations[*].Instances[?State.Name=='running'].InstanceId"

jq is the de facto standard for JSON processing on the command line. It has its own richer syntax, but many core ideas — .foo for property access, .[] for iteration, select() for filtering — map directly onto JSONPath concepts. Once you know JSONPath, picking up jq is straightforward.

JSONPath vs. JavaScript Dot-Notation Chaining

In JavaScript, plain property access (data.store.book[0].title) works fine for deterministic paths, but has real limits: if any intermediate property is undefined, the expression throws a TypeError. You need optional chaining (data?.store?.book?.[0]?.title) to be safe, and there's no built-in way to express "all elements" or "any depth."

JSONPath handles both cases with a single expression, and returns an array of matches (zero, one, or many) — which maps naturally onto scenarios expecting multiple results. For simple, known-path access, plain JS dot notation is fine. For flexible querying, filtering, and deep searches across variable-shaped data, a proper JSONPath library is the better tool.

Summary

The core operators to know: $ (root), . and [] (navigation), * (wildcard), .. (recursive descent), array slices ([0] / [-1] / [0:3]), and filter expressions ([?(@.price < 10)]). These seven cover the vast majority of real-world data-extraction tasks — for testing APIs, querying cloud resources, or processing large JSON payloads on the command line.

Want to test JSONPath expressions on your own data? JSON Formatter Hub lets you paste JSON and explore the structure interactively, entirely in your browser.

JSON Schema — How to Validate Your JSON Data Structure

Deepak Kumar — Sat, 22 Aug 2026 17:24:41 +0000

JSON doesn't enforce anything on its own. You can send {"age": "twelve"} to an endpoint expecting a number and the format won't complain — catching that is on you. JSON Schema is the standard way to stop doing that in scattered application code. It's a document, written in JSON itself, that describes the exact shape another JSON object must have: which fields are required, what types they hold, what patterns strings must match. Define it once and any conforming validator handles the checking — in JavaScript, Python, Java, Go, and most other languages with a maintained implementation.

The current spec version is draft 2020-12, published as an IETF draft. The version matters because keyword behavior changed between drafts — more on that below.

The `$schema` and `$id` Keywords

Every schema should start with two meta-keywords. $schema declares which version of the spec the document follows. $id gives the schema a canonical URI — useful when schemas reference each other or are published for others to consume.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/schemas/user-registration.json",
  "title": "User Registration",
  "description": "Schema for a new user sign-up payload",
  "type": "object"
}

Neither keyword is required for a schema to work locally, but including them is considered best practice and makes schemas self-documenting.

Core Keywords: `type`, `properties`, `required`, `additionalProperties`

type is the most fundamental constraint. Valid values are "string", "number", "integer", "boolean", "array", "object", and "null". You can also pass an array of types when a field may legitimately hold more than one, such as ["string", "null"] for a nullable field.

For objects, properties defines a schema for each named key, while required lists the keys that must be present. Note carefully: required only checks presence, not the value — a required field can still be null unless you also constrain its type. Setting additionalProperties to false rejects any key not listed under properties, useful for strict API contracts.

{
  "type": "object",
  "properties": {
    "username": { "type": "string" },
    "email": { "type": "string" },
    "age": { "type": "integer" }
  },
  "required": ["username", "email"],
  "additionalProperties": false
}

String Constraints

minLength and maxLength set character-count bounds. pattern accepts a regular expression (ECMA 262 dialect) the string must match. enum restricts the value to a fixed list, and format declares a semantic format like "email", "uri", "date", or "uuid" — though format validation is optional in many implementations and must be explicitly enabled.

{
  "username": {
    "type": "string",
    "minLength": 3,
    "maxLength": 30,
    "pattern": "^[a-zA-Z0-9_-]+$"
  },
  "email": {
    "type": "string",
    "format": "email"
  },
  "role": {
    "type": "string",
    "enum": ["admin", "editor", "viewer"]
  }
}

Number Constraints

Numbers can be bounded with minimum, maximum, exclusiveMinimum, and exclusiveMaximum. multipleOf enforces divisibility — useful for things like page sizes that must be multiples of 10, or currency amounts that must be multiples of 0.01.

{
  "age": {
    "type": "integer",
    "minimum": 13,
    "maximum": 120
  },
  "score": {
    "type": "number",
    "minimum": 0,
    "maximum": 100,
    "multipleOf": 0.5
  }
}

Array Validation

items provides a schema every element must satisfy. minItems and maxItems control array length, and uniqueItems: true requires no two elements be identical — handy for tag lists or permission sets.

{
  "tags": {
    "type": "array",
    "items": { "type": "string", "minLength": 1, "maxLength": 50 },
    "minItems": 1,
    "maxItems": 10,
    "uniqueItems": true
  }
}

Nested Schemas with `$ref` and `$defs`

Real schemas quickly grow complex. $defs (called definitions in older drafts) lets you define reusable sub-schemas in one place and reference them with $ref — avoiding copy-pasting the same address schema into every object that has a billing or shipping address.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$defs": {
    "address": {
      "type": "object",
      "properties": {
        "street": { "type": "string" },
        "city": { "type": "string" },
        "country": { "type": "string", "minLength": 2, "maxLength": 2 }
      },
      "required": ["street", "city", "country"]
    }
  },
  "type": "object",
  "properties": {
    "billingAddress": { "$ref": "#/$defs/address" },
    "shippingAddress": { "$ref": "#/$defs/address" }
  }
}

Complete Example: User Registration Payload

A realistic schema for a user registration API endpoint, combining type constraints, string validation, and required fields into a document you could drop into a validator today:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/schemas/register.json",
  "title": "User Registration",
  "type": "object",
  "properties": {
    "username": {
      "type": "string",
      "minLength": 3,
      "maxLength": 30,
      "pattern": "^[a-zA-Z0-9_-]+$"
    },
    "email": {
      "type": "string",
      "format": "email",
      "maxLength": 254
    },
    "password": {
      "type": "string",
      "minLength": 8,
      "maxLength": 128
    },
    "age": {
      "type": "integer",
      "minimum": 13
    },
    "newsletter": {
      "type": "boolean"
    },
    "interests": {
      "type": "array",
      "items": { "type": "string" },
      "maxItems": 20,
      "uniqueItems": true
    }
  },
  "required": ["username", "email", "password"],
  "additionalProperties": false
}

Validating with Ajv (JavaScript)

Ajv is the most widely used JSON Schema validator for JavaScript and Node.js. It compiles schemas to optimized validation functions, so repeated validations on the same schema are very fast. Install with npm install ajv:

import Ajv from "ajv";
import addFormats from "ajv-formats"; // for "email", "uri", etc.

const ajv = new Ajv();
addFormats(ajv);

const schema = {
  type: "object",
  properties: {
    username: { type: "string", minLength: 3 },
    email: { type: "string", format: "email" }
  },
  required: ["username", "email"]
};

const validate = ajv.compile(schema);

const data = { username: "alice", email: "alice@example.com" };
const valid = validate(data);

if (!valid) {
  console.error(validate.errors);
} else {
  console.log("Data is valid");
}

The validate.errors array contains structured error objects with a message, a JSON Pointer instancePath pointing to the failing field, and a keyword indicating which constraint was violated — making it straightforward to map errors back to form fields in a UI.

Validating with `jsonschema` (Python)

The jsonschema library is the standard choice in Python. Install with pip install jsonschema. The simplest usage calls validate(), which raises a ValidationError on failure:

import json
from jsonschema import validate, ValidationError

schema = {
    "type": "object",
    "properties": {
        "username": {"type": "string", "minLength": 3},
        "email": {"type": "string", "format": "email"}
    },
    "required": ["username", "email"]
}

payload = {"username": "alice", "email": "alice@example.com"}

try:
    validate(instance=payload, schema=schema)
    print("Valid")
except ValidationError as e:
    print(f"Invalid: {e.message}")
    print(f"Field path: {list(e.absolute_path)}")

For validating many documents against the same schema, create a jsonschema.Draft202012Validator instance once and call its validate() method repeatedly to avoid re-parsing the schema on every call.

Testing Your Schemas

Before wiring a schema into application code, test it manually with sample payloads — both valid ones and deliberately broken ones that should fail. Paste your JSON into a formatter first to ensure it's well-formed before feeding it to a validator; catching a missing comma in your test data first saves confusion about whether the schema or the data is wrong.

JSON Schema is a powerful contract mechanism that moves validation logic out of imperative code and into a declarative, language-agnostic document. Once you have a schema, you can share it with API consumers, generate documentation from it, use it in CI to gate malformed requests, and even derive TypeScript types from it with tools like json-schema-to-typescript.

If you're testing a schema right now, JSON Formatter Hub formats and validates JSON entirely in your browser — a quick way to confirm your test payloads are well-formed before you throw them at a validator.

REST API JSON Best Practices — Design Patterns Every Developer Should Know

Deepak Kumar — Sat, 22 Aug 2026 17:20:55 +0000

A well-designed JSON API is a joy to consume. A poorly designed one creates bugs, confusion, and endless Slack threads asking "what does this field actually mean?" The decisions you make about naming, error formats, pagination, and date handling ripple through every client that ever calls your API. This covers the patterns that separate maintainable APIs from painful ones, with concrete JSON examples for each.

1. Field Naming Conventions

Pick snake_case or camelCase and be consistent across every endpoint. The worst choice is mixing them.

// snake_case (most common in Python/Ruby APIs)
{
  "user_id": 42,
  "first_name": "Alice",
  "last_login_at": "2025-05-01T10:30:00Z",
  "is_active": true
}

// camelCase (most common in JavaScript/Node APIs)
{
  "userId": 42,
  "firstName": "Alice",
  "lastLoginAt": "2025-05-01T10:30:00Z",
  "isActive": true
}

Both are fine. The critical rule: never mix. A response body with user_id alongside firstName is a maintenance nightmare.

Naming rules that hold regardless of case style:

Plural nouns for collections: users, orders, line_items
Boolean fields with is/has/can prefix: is_active, has_children, can_edit
No abbreviations: description not desc, quantity not qty
IDs as strings if they exceed 53 bits — JavaScript's Number can't safely represent integers above 2⁵³ − 1:

// IDs from distributed systems (Snowflake IDs, etc.) should be strings
{
  "id": "7823648237462834762",  // string — safe in all languages
  "order_number": 10045          // small integer — fine as number
}

2. Response Structure

Wrap your response in a consistent envelope. Clients should be able to predict the shape of every response without reading the documentation.

// Single resource response
{
  "data": {
    "id": "usr_42",
    "name": "Alice",
    "email": "alice@example.com",
    "created_at": "2024-01-15T08:00:00Z"
  }
}

// Collection response
{
  "data": [
    { "id": "usr_42", "name": "Alice" },
    { "id": "usr_43", "name": "Bob" }
  ],
  "meta": {
    "total": 248,
    "page": 1,
    "per_page": 20
  }
}

The data wrapper lets you add meta, links, or other top-level fields later without breaking existing clients:

// BAD: bare array — can never add metadata without breaking clients
[
  { "id": 1, "name": "Alice" },
  { "id": 2, "name": "Bob" }
]

// GOOD: wrapped — extensible
{
  "data": [
    { "id": 1, "name": "Alice" },
    { "id": 2, "name": "Bob" }
  ]
}

3. Error Response Format

Error responses are where the most inconsistency lives. Pick a format and enforce it via middleware so every error — including 500s — returns the same shape.

{
  "error": {
    "code": "VALIDATION_FAILED",
    "message": "Request body validation failed",
    "details": [
      { "field": "email", "message": "Must be a valid email address", "value": "not-an-email" },
      { "field": "age", "message": "Must be a positive integer", "value": -5 }
    ],
    "request_id": "req_8f3k2j9s"
  }
}

code — machine-readable string constant clients can switch on. Never change these once published.
message — human-readable, can change. For debugging, not UI display.
details — array of field-level errors for validation failures.
request_id — correlates the error to a server log entry. Invaluable for support.

HTTP Status	Error Code	When to Use
400	`VALIDATION_FAILED`	Request body or query params failed validation
401	`UNAUTHORIZED`	No valid authentication credentials
403	`FORBIDDEN`	Authenticated but not permitted
404	`NOT_FOUND`	Resource does not exist
409	`CONFLICT`	Optimistic lock failure, duplicate key
422	`UNPROCESSABLE`	Syntactically valid but semantically wrong
429	`RATE_LIMITED`	Too many requests
500	`INTERNAL_ERROR`	Unexpected server error

Always pair the HTTP status code with a machine-readable code field. The status tells the client the category; the code tells it the specific cause.

4. Pagination

Three patterns exist, each with tradeoffs.

// Offset pagination — Request: GET /users?page=3&per_page=20
{
  "data": [ ],
  "meta": { "total": 248, "page": 3, "per_page": 20, "total_pages": 13 },
  "links": {
    "first": "/users?page=1&per_page=20",
    "prev": "/users?page=2&per_page=20",
    "next": "/users?page=4&per_page=20",
    "last": "/users?page=13&per_page=20"
  }
}

Pros: can jump to any page, easy to implement. Cons: skips or duplicates records if the dataset changes mid-pagination; slow on large tables (SQL OFFSET 10000 scans 10,000 rows).

// Cursor pagination — Request: GET /events?limit=20&after=cursor_abc123
{
  "data": [ ],
  "meta": { "has_next_page": true, "has_prev_page": true },
  "links": {
    "next": "/events?limit=20&after=cursor_xyz789",
    "prev": "/events?limit=20&before=cursor_abc123"
  }
}

Pros: stable — new inserts don't cause duplicates or skips; efficient — keyset pagination uses an index. Cons: can't jump to page 7; total count is expensive to compute.

Use cursor pagination for feeds, timelines, and any high-write collection. Use offset pagination for admin tables where users need to jump to specific pages. Always include next/prev links in the response so clients don't have to construct URLs themselves.

5. Dates and Times

Use ISO 8601 with UTC timezone for all timestamps. Full stop.

// GOOD
{
  "created_at": "2025-05-01T10:30:00Z",       // UTC
  "scheduled_at": "2025-06-15T14:00:00+05:30", // with offset if timezone matters
  "birth_date": "1990-07-22"                   // date-only when time is irrelevant
}

// BAD
{
  "created_at": "May 1, 2025",        // ambiguous, not machine-parseable
  "created_at": 1746094200,           // Unix timestamp — readable but not self-documenting
  "created_at": "01/05/2025 10:30"    // is that May 1 or January 5?
}

Always include time zone — 2025-05-01T10:30:00 without one is ambiguous.
Use Z suffix for UTC; use +HH:MM offset only when local timezone is meaningful.
Use date-only format (YYYY-MM-DD) when time of day genuinely doesn't matter.
Never use Unix timestamps as your primary format — they require documentation to interpret.

For durations, always encode the unit in the field name:

{
  "timeout_seconds": 30,
  "retry_interval_ms": 500,
  "session_duration": "PT1H30M"
}

timeout: 30 is seconds? milliseconds? minutes? You'll get it wrong and break something.

6. Null vs Missing Fields

null and a missing field mean different things.

// Field present and null — the value exists, explicitly set to null
{ "name": "Alice", "middle_name": null }

// Field absent — you don't know or it doesn't apply
{ "name": "Alice" }

Include with null when the field is part of the resource schema but has no value — clients can rely on the key always being present.
Omit entirely for optional metadata that may not apply.
Never use empty string as null — an empty string is a valid value (zero characters), not a sentinel for "no value."

7. Versioning

Plan for breaking changes from day one.

GET /v1/users
GET /v2/users

URL versioning is simple, explicit, and cacheable — the version is visible in every log entry. Header versioning (Accept: application/vnd.myapi.v2+json) keeps URLs clean but requires clients to set headers correctly.

Breaking	Non-breaking (safe to ship)
Removing a field	Adding a new optional field
Renaming a field	Adding a new endpoint
Changing a field's type	Adding a new HTTP method to an endpoint
Changing error codes	Making a required field optional
Changing auth requirements	Adding new valid enum values (controversial)

8. Anti-Patterns to Avoid

Using HTTP 200 for errors:

// BAD — client has to parse body to detect failure
HTTP 200 OK
{ "success": false, "error": "User not found" }

// GOOD — HTTP status communicates outcome
HTTP 404 Not Found
{ "error": { "code": "NOT_FOUND", "message": "User with id usr_999 does not exist" } }

Inconsistent ID types across endpoints:

// BAD
GET /users/42 → { "id": 42 }
GET /orders/42 → { "id": "ord_42" }

// GOOD — consistent format everywhere
GET /users/usr_42 → { "id": "usr_42" }
GET /orders/ord_42 → { "id": "ord_42" }

Encoding data in field names:

// BAD — field names change with data
{ "price_usd": 10.99, "price_eur": 9.50, "price_gbp": 8.75 }

// GOOD — structure encodes the variation
{ "prices": [
  { "currency": "USD", "amount": 10.99 },
  { "currency": "EUR", "amount": 9.50 },
  { "currency": "GBP", "amount": 8.75 }
] }

Deeply nested responses:

// BAD — three levels deep to reach the data
{ "response": { "body": { "result": { "users": [] } } } }

// GOOD — data at predictable depth
{ "data": [] }

Exposing internal implementation details:

// BAD — reveals DB column names, ORM internals
{ "tbl_usr_id": 42, "__v": 0, "_id": "507f1f77bcf86cd799439011" }

// GOOD — API shape is independent of storage
{ "id": "usr_42", "created_at": "2025-05-01T10:30:00Z" }

Summary

Concern	Recommendation
Field naming	`snake_case` or `camelCase` — pick one, enforce it everywhere
Response shape	Wrap in `data` key; never bare arrays at top level
Error format	Consistent envelope: `code`, `message`, `details`, `request_id`
HTTP status codes	Use them correctly — 200 means success
Pagination	Cursor for feeds; offset for admin; always include links
Dates	ISO 8601 with UTC (`Z` suffix), always
Null handling	`null` = known absence; omit = not applicable
IDs	Strings for large IDs; consistent prefix per resource type
Versioning	URL versioning for simplicity; plan for breaking changes

Well-designed JSON APIs aren't just easier to consume — they're easier to maintain. When the response shape is consistent, clients are more resilient, debugging is faster, and adding new features doesn't require coordinating SDK changes across every consumer.

If you're debugging an API response right now, JSON Formatter Hub formats, validates, and lets you explore it in a tree/table view — entirely in your browser.

JSON Web Tokens (JWT) Explained — Structure, Use Cases, and Security

Deepak Kumar — Mon, 17 Aug 2026 10:16:35 +0000

A JSON Web Token (JWT) is a compact, URL-safe way to transmit claims between two parties. It's used almost universally for API authentication — when a user logs in, the server issues a JWT; the client stores it and sends it with every subsequent request. The server verifies the token's signature without looking anything up in a database. Understanding exactly how JWTs work — and where they go wrong — is essential for any developer building an API.

The Three-Part Structure

A JWT looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIiwiaWF0IjoxNzE1MzM2MDAwLCJleHAiOjE3MTUzMzk2MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Three base64url-encoded sections, separated by dots: header.payload.signature.

Part 1: Header

Decode the first section and you get a JSON object describing the token type and signing algorithm:

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

Common algorithms: HS256 (HMAC-SHA256, symmetric — one shared secret), RS256 (RSA-SHA256, asymmetric — private key signs, public key verifies).

Part 2: Payload (Claims)

The payload carries the actual data — called claims:

{
  "sub": "1234567890",
  "name": "Alice",
  "email": "alice@example.com",
  "role": "admin",
  "iat": 1715336000,
  "exp": 1715339600,
  "iss": "https://auth.example.com",
  "aud": "https://api.example.com"
}

Standard registered claims:

sub — subject (usually a user ID)
iat — issued at (Unix timestamp)
exp — expiration time (Unix timestamp)
iss — issuer (who created the token)
aud — audience (who should accept the token)
nbf — not before (token is invalid before this time)

Part 3: Signature

The signature is computed over the encoded header and payload using the algorithm and secret:

HMACSHA256(
  base64url(header) + "." + base64url(payload),
  secret
)

The signature cannot be forged without the secret. If the payload is tampered with, the signature won't match and the token is rejected. Note: the payload is encoded, not encrypted — anyone can read it by base64-decoding it.

How to Decode a JWT (Without Verifying)

To inspect a token's payload for debugging (don't rely on this for authorization):

// JavaScript — decode without verifying signature
function decodeJWT(token) {
  const parts = token.split('.');
  if (parts.length !== 3) throw new Error('Invalid JWT');
  const payload = parts[1].replace(/-/g, '+').replace(/_/g, '/');
  return JSON.parse(atob(payload));
}

const claims = decodeJWT('eyJhbGci...');
console.log(claims.sub); // user ID
console.log(new Date(claims.exp * 1000)); // expiry date

Creating and Verifying JWTs

JavaScript (jsonwebtoken library):

const jwt = require('jsonwebtoken');

const SECRET = process.env.JWT_SECRET; // store in env, never hardcode

// Sign a token (expires in 1 hour)
const token = jwt.sign(
  { sub: user.id, name: user.name, role: user.role },
  SECRET,
  { expiresIn: '1h', issuer: 'https://auth.example.com' }
);

// Verify and decode
try {
  const payload = jwt.verify(token, SECRET, {
    issuer: 'https://auth.example.com'
  });
  console.log(payload.sub);
} catch (err) {
  // TokenExpiredError, JsonWebTokenError, NotBeforeError
  console.error('Invalid token:', err.message);
}

Python (PyJWT library):

import jwt
from datetime import datetime, timedelta, timezone

SECRET = 'your-secret-key'

# Sign
payload = {
    'sub': str(user.id),
    'name': user.name,
    'iat': datetime.now(timezone.utc),
    'exp': datetime.now(timezone.utc) + timedelta(hours=1)
}
token = jwt.encode(payload, SECRET, algorithm='HS256')

# Verify
try:
    decoded = jwt.decode(token, SECRET, algorithms=['HS256'])
    print(decoded['sub'])
except jwt.ExpiredSignatureError:
    print('Token expired')
except jwt.InvalidTokenError as e:
    print(f'Invalid token: {e}')

HS256 vs RS256: Which to Use

Algorithm	Type	Signs with	Verifies with	Best for
HS256	Symmetric	Shared secret	Same secret	Single-service apps where server signs and verifies
RS256	Asymmetric	Private key	Public key	Microservices — auth server signs, multiple services verify without the private key
ES256	Asymmetric (ECDSA)	Private key	Public key	Same as RS256 but smaller key size

Security Pitfalls

The "alg: none" attack

Early JWT libraries accepted tokens with "alg": "none" and no signature, treating them as valid. Always explicitly specify which algorithms you accept when verifying — never pass an empty or wildcard list:

// WRONG — accepts any algorithm including "none"
jwt.verify(token, secret);

// CORRECT — whitelist the expected algorithm
jwt.verify(token, secret, { algorithms: ['HS256'] });

localStorage vs httpOnly cookie

Storing a JWT in localStorage makes it readable by any JavaScript on the page, including injected scripts (XSS). Storing it in an httpOnly cookie means JavaScript can't read it, but you must also set SameSite=Strict or SameSite=Lax to prevent CSRF. For most applications, httpOnly cookies are safer.

Keep expiry short, use refresh tokens

A stolen JWT can't be invalidated (JWTs are stateless). Short-lived access tokens (15 minutes to 1 hour) combined with longer-lived refresh tokens minimize the damage window.

Validate `iss` and `aud` claims

Always verify iss (issuer) and aud (audience) in addition to the signature and expiry. A token issued by one service shouldn't be accepted by another service even if the signature is valid.

What NOT to store in a JWT payload

The payload is base64-encoded, not encrypted — anyone with the token can read it. Never put passwords, credit card numbers, social security numbers, or other sensitive PII in the payload.

Complete Authentication Flow with JWT

User submits credentials — the client sends username and password to POST /auth/login.
Server validates credentials — checks the password hash in the database.
Server issues tokens — returns a short-lived access token (15–60 min) and a long-lived refresh token (7–30 days).
Client stores tokens — access token in memory or a session variable; refresh token in an httpOnly cookie.
Client sends the access token — every API request includes Authorization: Bearer <access_token>.
Server verifies the token — checks signature, expiry, issuer, and audience. No database call needed.
Access token expires — the client sends the refresh token to POST /auth/refresh to get a new access token.
User logs out — the client discards the access token; the server invalidates the refresh token in a revocation store.

The Refresh Token Pattern

const jwt = require('jsonwebtoken');

const ACCESS_SECRET = process.env.ACCESS_TOKEN_SECRET;
const REFRESH_SECRET = process.env.REFRESH_TOKEN_SECRET;

function issueTokens(userId, role) {
  const accessToken = jwt.sign(
    { sub: userId, role },
    ACCESS_SECRET,
    { expiresIn: '15m', issuer: 'https://auth.example.com' }
  );

  const refreshToken = jwt.sign(
    { sub: userId },
    REFRESH_SECRET,
    { expiresIn: '7d', issuer: 'https://auth.example.com' }
  );

  return { accessToken, refreshToken };
}

// Refresh endpoint
app.post('/auth/refresh', (req, res) => {
  const token = req.cookies.refreshToken; // httpOnly cookie
  if (!token) return res.status(401).json({ error: 'No refresh token' });

  try {
    const payload = jwt.verify(token, REFRESH_SECRET, {
      issuer: 'https://auth.example.com'
    });
    const { accessToken } = issueTokens(payload.sub, payload.role);
    res.json({ accessToken });
  } catch (err) {
    res.status(403).json({ error: 'Invalid or expired refresh token' });
  }
});

JWT Revocation Strategies

JWTs are stateless by design — there's no built-in way to invalidate a token before it expires. Practical patterns used in production:

Short expiry — the simplest strategy. If access tokens expire in 15 minutes, a stolen token is only useful for 15 minutes at most.
Refresh token revocation list — store refresh token IDs (the jti claim) in Redis or a database, checked on each refresh. Log out by adding the ID to the revocation list.
Token rotation — issue a new refresh token on every use and invalidate the old one. If a stolen token is used, the legitimate user's next request fails, alerting the system.
Version claim — store a tokenVersion integer on the user record. Embed it in the JWT, verify on each request, increment to invalidate all existing tokens for that user.

Common JWT Mistakes

Mistake	Risk	Fix
Hardcoding the secret in source code	Secret leaked in git history	Load from environment variable or secrets manager
Using a weak or short secret for HS256	Brute-forced offline	Use a 256-bit+ random secret; prefer RS256 for distributed systems
Not verifying `exp`	Expired tokens accepted forever	Always verify — most libraries do this by default
Not verifying `iss` and `aud`	Token from another service accepted	Pass expected issuer and audience to the verify call
Storing sensitive data in payload	Payload readable by anyone with the token	Store only user ID and role; fetch sensitive data server-side
Storing access token in localStorage	Exposed to XSS attacks	Keep access token in memory; refresh token in httpOnly cookie

If you're debugging a token right now, the JWT Decoder lets you paste one in and see the header, payload, and expiry status instantly, entirely in your browser.

How to Handle Large JSON Files Without Crashing Your Browser

Deepak Kumar — Thu, 30 Jul 2026 08:42:35 +0000

Files over 10 MB will slow most browser tools; over 50 MB will crash them. Here's how to handle large JSON without losing your mind.

JSON.parse() loads the entire file into memory before returning anything. For small files this is fine. For a 100MB database export, it will exhaust browser memory and crash the tab. This covers the practical strategies that actually work when JSON is too large to handle with standard tools.

The Problem: In-Memory Parsing

Every standard JSON parser — in browsers, Node.js, Python, and Java — works by reading the entire input, building a complete in-memory representation, and then returning it. A 100MB JSON file can expand to 500MB–1GB in memory, because the in-memory object graph has overhead for each key, value, and reference. Browser tabs typically have 512MB–2GB of memory limits and no swap. The result is a hard crash.

Rule of thumb:

Under 5MB: any browser formatter works fine
5–20MB: browser tools are slow but may work; use the strategies below for speed
Over 20MB: use command-line tools or streaming parsers

Strategy 1: jq — The JSON Swiss Army Knife

jq is a lightweight command-line JSON processor. It streams through the file without loading everything into memory and lets you filter, transform, and extract data.

# Pretty-print the first 10 array elements
jq '.[0:10]' large-data.json

# Get all keys of the root object
jq 'keys' large-data.json

# Count array items
jq 'length' large-data.json

# Extract a specific field from every object in an array
jq '.[].email' users.json

# Filter: only objects where age > 30
jq '[.[] | select(.age > 30)]' users.json

# Get only specific fields from each object
jq '[.[] | {name, email}]' users.json

# Convert array of objects to CSV
jq -r '.[] | [.name, .email, .age | tostring] | join(",")' users.json

Extract just the part you need, then use a browser formatter for the rest:

jq '.config.database' app-config.json > database-config.json
# Now paste database-config.json into a browser formatter

Strategy 2: Streaming Parsers (Node.js)

The stream-json npm package streams JSON token by token, so memory usage stays constant regardless of file size:

const { createReadStream } = require('fs');
const { chain } = require('stream-chain');
const { parser } = require('stream-json');
const { streamArray } = require('stream-json/streamers/StreamArray');

let count = 0;
chain([
  createReadStream('large-users.json'),
  parser(),
  streamArray()
]).on('data', ({ value }) => {
  // Process one object at a time — constant memory
  console.log(value.email);
  count++;
}).on('end', () => {
  console.log(`Processed ${count} records`);
});

Strategy 3: Streaming Parsers (Python)

ijson is the Python equivalent — it iterates over items in a large JSON array without loading the whole file:

import ijson

with open('large-users.json', 'rb') as f:
    for user in ijson.items(f, 'item'):
        # 'item' = each element of the top-level array
        print(user['email'])
        # Process one record at a time

For deeply nested paths:

import ijson

with open('response.json', 'rb') as f:
    # Extract items from data.users array
    for user in ijson.items(f, 'data.users.item'):
        process(user)

Strategy 4: Split the File into Chunks

If you need to work with all the data in a browser tool, split the large array into smaller files first.

# Using jq — split a 100,000-item array into chunks of 1,000
jq -c '.[]' large.json | split -l 1000 - chunk_
for f in chunk_*; do
  jq -s '.' "$f" > "${f}.json"
done

# Using Python
import json

CHUNK_SIZE = 1000

with open('large.json') as f:
    data = json.load(f)  # Still loads all into memory once

for i in range(0, len(data), CHUNK_SIZE):
    chunk = data[i:i + CHUNK_SIZE]
    with open(f'chunk_{i // CHUNK_SIZE}.json', 'w') as out:
        json.dump(chunk, out, indent=2)

Strategy 5: Import into a Database

For very large files (hundreds of MB or more) that you need to query repeatedly, importing into a database is the right long-term approach.

-- SQLite with JSON support
CREATE TABLE users AS
SELECT
  json_extract(value, '$.id') AS id,
  json_extract(value, '$.name') AS name,
  json_extract(value, '$.email') AS email
FROM json_each(readfile('users.json'));

-- PostgreSQL JSONB
COPY staging(raw) FROM '/path/to/data.json';
SELECT raw->>'name', raw->>'email'
FROM staging
WHERE (raw->>'age')::int > 30;

Strategy 6: JSONL (Newline-Delimited JSON)

If you control the data source, use JSONL format for large datasets. Each line is a valid, standalone JSON object — enabling line-by-line processing with standard Unix tools, no special parser needed.

{"id":1,"name":"Alice","email":"alice@example.com"}
{"id":2,"name":"Bob","email":"bob@example.com"}

wc -l data.jsonl                # Count lines (= record count)
jq -r '.email' data.jsonl       # Extract a field from every line
jq 'select(.age > 30)' data.jsonl  # Filter

with open('data.jsonl') as f:
    for line in f:
        record = json.loads(line.strip())
        process(record)

Summary: Which Strategy to Use

File Size	Best Approach
Under 5MB	Browser formatter
5–50MB	`jq` to extract the section you need, then browser tool
50MB–1GB	Streaming parser (`stream-json` / `ijson`) or `jq`
Over 1GB	Database import (SQLite or PostgreSQL)
Any size, repeated queries	Convert to JSONL or import to database

Compressing Large JSON for Storage and Transfer

A 100MB JSON file often compresses to 10–20MB with gzip, because JSON is highly repetitive text (repeated key names, whitespace, common values). Compression is almost always worth enabling for large JSON transmitted over HTTP.

gzip -k large-data.json          # creates large-data.json.gz, keeps original
gzip -d large-data.json.gz       # decompress
jq '.[]' large-data.json | gzip > extracted.jsonl.gz

// Node.js — stream with compression
const { createReadStream, createWriteStream } = require('fs');
const { createGzip } = require('zlib');

createReadStream('data.json')
  .pipe(createGzip())
  .pipe(createWriteStream('data.json.gz'))
  .on('finish', () => console.log('Compressed'));

For HTTP APIs, enable gzip on the server and set Accept-Encoding: gzip on the client. Most frameworks (Express, FastAPI, Spring Boot) have a one-line setting for this.

Diagnosing Memory Problems

Check the file size first — ls -lh data.json. Anything over 10MB shouldn't go into a browser formatter.
Count records without loading — jq 'length' data.json, or wc -l data.jsonl for JSONL. Know what you're dealing with before committing to loading everything.
Sample first — jq '.[0]' data.json to check structure before processing everything.
Profile Node.js memory — node --max-old-space-size=4096 script.js. If it still crashes, you need a streaming approach.
Python's memory_profiler — pip install memory-profiler, then mprof run script.py for per-line memory usage.

Large JSON in Cloud Storage

When large JSON files live in cloud storage, you have options that avoid downloading the whole file:

S3 Select — Amazon S3 can run SQL-like queries directly on JSON/CSV files in S3, returning only matching rows. You pay only for data scanned, far cheaper than downloading a 1GB file to extract 1,000 rows.
BigQuery external tables — query JSONL files in Cloud Storage directly, without importing them.
Azure Blob with Apache Spark — for multi-GB files, PySpark distributes parsing across a cluster.
Convert to Parquet — for repeated queries, Parquet reduces file size 5–10x and makes column-oriented queries 10–100x faster.

# Convert JSONL to Parquet with pandas
import pandas as pd

df = pd.read_json('large-data.jsonl', lines=True)
df.to_parquet('data.parquet', compression='snappy')

# Later: read back only the columns you need
df2 = pd.read_parquet('data.parquet', columns=['name', 'email', 'age'])

If you're under the 5MB threshold, JSON Formatter Hub handles formatting, validation, and tree/table views entirely in your browser — no upload required.

Why I Built a JSON Formatter That Never Sends Your Data Anywhere

Deepak Kumar — Thu, 23 Jul 2026 17:32:52 +0000

Every JSON formatter online does the same basic job: parse, validate, pretty-print. But most of them make the same architectural choice I decided not to make — they send your JSON to a server first.

I'm Deepak Kumar, a full-stack developer, and I built JSON Formatter Hub specifically to avoid that. Here's why it matters, and how the client-side version actually works.

The problem with server-side formatting

Think about what people actually paste into a JSON formatter: API responses, auth tokens, database exports, config files, sometimes entire request payloads with PII in them. A tool that uploads that to a backend — even briefly, even without storing it — is a tool you have to trust with data you probably shouldn't be sharing with a third party at all.

This isn't hypothetical. Newer "AI-powered" JSON tools go a step further: they pipe your JSON to an LLM API to generate explanations or fix errors. That means your data now also passes through a third-party AI provider's infrastructure. For anything containing credentials or user data, that's a meaningfully larger exposure surface than people realize.

Doing it entirely in the browser

The alternative is straightforward in principle, less so in practice: do everything with JSON.parse, JSON.stringify, and vanilla DOM rendering, entirely client-side.

A few specifics from building it:

Validation with useful error location. JSON.parse throws on invalid input, but the error message alone isn't enough for a developer to fix a 2000-line payload. I wrap it and back-calculate line/column from the character position in the error:

function validateJSON(input) {
  try {
    JSON.parse(input);
    return { valid: true };
  } catch (err) {
    const match = /position (\d+)/.exec(err.message);
    let line = null, column = null;
    if (match) {
      const pos = parseInt(match[1], 10);
      const lines = input.slice(0, pos).split('\n');
      line = lines.length;
      column = lines[lines.length - 1].length + 1;
    }
    return { valid: false, message: err.message, line, column };
  }
}

Tree and table views without a parsing library. Since the input is already a JS object after JSON.parse, tree view is just recursive DOM generation over that object — no separate parser needed. Table view is a flatten step: collect the union of keys across array entries, then map each row against that column set.

Large files. Pretty-printing a multi-megabyte JSON file synchronously can freeze the tab. Deferring the heavy formatting work and rendering progressively keeps the UI responsive without needing a server round-trip to do the same job slower.

The full implementation is open on GitHub: jsonformatterhub/jsonformatterhub.

Try it

JSON Formatter Hub is free, has no login, and — because of everything above — never sees your data. Format, validate, beautify, minify, or convert JSON to XML/CSV/YAML, all in your browser.

If you build developer tools yourself, I'd be curious whether you've made the same client-side-first call, or where it hasn't been worth it for you.

Online JSON Formatter and Validator for Developers

Deepak Kumar — Wed, 17 Dec 2025 17:55:32 +0000

JSON is widely used in APIs and web applications, but unformatted JSON can be hard to read and debug.

Free Online JSON Formatter and Validator

I built JSON Formatter Hub to help developers format, validate, beautify, and minify JSON quickly.

🔗 Tool link: https://jsonformatterhub.com/

What you can do with JSON Formatter Hub

Format JSON instantly
Validate JSON structure
Beautify or minify JSON
Convert JSON to XML, CSV, or YAML

Why use it?

No signup required
Runs fully in the browser
Fast and simple UI
Free for everyone

If you work with APIs or JSON data regularly, this tool can save you time.

👉 Try it here: https://jsonformatterhub.com/

DEV Community: Deepak Kumar

JSONPath — How to Query and Filter JSON Data

What Is JSONPath and Why Does It Matter?

The Root Operator and Basic Navigation

Wildcards and Recursive Descent

Array Slicing and Index Access

Filter Expressions

Built-in Functions

Practical Examples

Where JSONPath Is Used in Practice

JSONPath vs. JavaScript Dot-Notation Chaining

Summary

JSON Schema — How to Validate Your JSON Data Structure

The $schema and $id Keywords

Core Keywords: type, properties, required, additionalProperties

String Constraints

Number Constraints

Array Validation

Nested Schemas with $ref and $defs

Complete Example: User Registration Payload

Validating with Ajv (JavaScript)

Validating with jsonschema (Python)

Testing Your Schemas

REST API JSON Best Practices — Design Patterns Every Developer Should Know

1. Field Naming Conventions

2. Response Structure

3. Error Response Format

4. Pagination

5. Dates and Times

6. Null vs Missing Fields

7. Versioning

8. Anti-Patterns to Avoid

Summary

JSON Web Tokens (JWT) Explained — Structure, Use Cases, and Security

The Three-Part Structure

Part 1: Header

Part 2: Payload (Claims)

Part 3: Signature

How to Decode a JWT (Without Verifying)

Creating and Verifying JWTs

HS256 vs RS256: Which to Use

Security Pitfalls

The "alg: none" attack

localStorage vs httpOnly cookie

Keep expiry short, use refresh tokens

Validate iss and aud claims

What NOT to store in a JWT payload

Complete Authentication Flow with JWT

The Refresh Token Pattern

JWT Revocation Strategies

Common JWT Mistakes

How to Handle Large JSON Files Without Crashing Your Browser

The Problem: In-Memory Parsing

Strategy 1: jq — The JSON Swiss Army Knife

Strategy 2: Streaming Parsers (Node.js)

Strategy 3: Streaming Parsers (Python)

Strategy 4: Split the File into Chunks

Strategy 5: Import into a Database

Strategy 6: JSONL (Newline-Delimited JSON)

Summary: Which Strategy to Use

Compressing Large JSON for Storage and Transfer

Diagnosing Memory Problems

Large JSON in Cloud Storage

Why I Built a JSON Formatter That Never Sends Your Data Anywhere

The problem with server-side formatting

Doing it entirely in the browser

Try it

Online JSON Formatter and Validator for Developers

Free Online JSON Formatter and Validator

What you can do with JSON Formatter Hub

Why use it?

The `$schema` and `$id` Keywords

Core Keywords: `type`, `properties`, `required`, `additionalProperties`

Nested Schemas with `$ref` and `$defs`

Validating with `jsonschema` (Python)

Validate `iss` and `aud` claims