DEV Community: Deepak Kumar

JSON in Databases — PostgreSQL JSONB, MySQL JSON, and MongoDB

Deepak Kumar — Fri, 28 Aug 2026 17:25:32 +0000

Most production databases now let you store JSON directly in a column and query into it — no separate document store required. But "supports JSON" means very different things depending on the engine: PostgreSQL's JSONB is a fully indexed binary format with a rich operator set, MySQL's JSON type is more limited, and MongoDB treats JSON-like documents (BSON) as its native storage model rather than an add-on. Here's how the three actually compare, with working query examples.

PostgreSQL: JSON vs JSONB

PostgreSQL ships two JSON column types. json stores an exact text copy of the input, preserving whitespace and key order, and re-parses on every read. jsonb stores a decomposed binary representation — it's slightly slower to write (it has to parse and normalize on insert), but significantly faster to query, and it's the type you should default to unless you have a specific reason to keep the original text verbatim.

CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    name TEXT,
    attributes JSONB
);

INSERT INTO products (name, attributes) VALUES
('Wireless Mouse', '{"color": "black", "wireless": true, "price": 29.99, "tags": ["electronics", "peripheral"]}');

PostgreSQL's JSONB operators are what make it genuinely pleasant to query:

-- -> returns a JSON value; ->> returns text
SELECT attributes->'color' FROM products;   -- "black" (jsonb)
SELECT attributes->>'color' FROM products;  -- black (text)

-- @> containment: does the column contain this JSON fragment?
SELECT * FROM products WHERE attributes @> '{"wireless": true}';

-- ? key existence
SELECT * FROM products WHERE attributes ? 'tags';

-- #>> path extraction, for nested values
SELECT attributes #>> '{specs,weight}' FROM products;

-- jsonb_array_elements to unnest an array field into rows
SELECT jsonb_array_elements_text(attributes->'tags') FROM products;

Crucially, JSONB columns can be indexed with a GIN index, which makes containment (@>) and key-existence (?) queries fast even on millions of rows:

CREATE INDEX idx_products_attributes ON products USING GIN (attributes);

This is the single biggest reason teams reach for PostgreSQL JSONB over MySQL JSON when the workload involves filtering on JSON contents at scale — without a GIN index, JSON queries in either engine degrade to a full table scan.

MySQL: The JSON Column Type

MySQL 5.7+ has a native JSON type that validates input and stores it in an optimized binary form (comparable in spirit to JSONB, though with a narrower operator set):

CREATE TABLE products (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255),
    attributes JSON
);

INSERT INTO products (name, attributes) VALUES
('Wireless Mouse', '{"color": "black", "wireless": true, "price": 29.99, "tags": ["electronics", "peripheral"]}');

Querying uses path expressions with dedicated functions rather than PostgreSQL-style operators:

-- JSON_EXTRACT (or the -> shorthand) to pull a value
SELECT JSON_EXTRACT(attributes, '$.color') FROM products;
SELECT attributes->'$.color' FROM products;   -- shorthand, same result
SELECT attributes->>'$.color' FROM products;  -- unquoted text result

-- JSON_CONTAINS for containment checks
SELECT * FROM products WHERE JSON_CONTAINS(attributes, 'true', '$.wireless');

-- JSON_TABLE (MySQL 8.0+) to expand a JSON array into rows
SELECT jt.tag
FROM products, JSON_TABLE(attributes, '$.tags[*]' COLUMNS (tag VARCHAR(50) PATH '$')) AS jt;

MySQL supports generated columns as a workaround for indexing a value buried inside JSON — you extract the value into a virtual column, then index that column directly:

ALTER TABLE products
ADD COLUMN wireless_flag BOOLEAN
GENERATED ALWAYS AS (JSON_EXTRACT(attributes, '$.wireless')) VIRTUAL,
ADD INDEX idx_wireless (wireless_flag);

This gets you indexed lookups on specific JSON fields, but it's more manual than PostgreSQL's GIN index over the whole document — you need to know in advance which paths you'll query frequently.

MongoDB: JSON as the Native Model

MongoDB doesn't bolt JSON onto a relational table — documents (technically BSON, a binary superset of JSON with extra types like native dates and integers) are the fundamental storage unit:

db.products.insertOne({
  name: "Wireless Mouse",
  attributes: {
    color: "black",
    wireless: true,
    price: 29.99,
    tags: ["electronics", "peripheral"]
  }
});

Because the whole document is JSON-shaped, queries read naturally without path-extraction functions:

// Find by a nested field directly
db.products.find({ "attributes.wireless": true });

// Find where a tags array contains a value
db.products.find({ "attributes.tags": "electronics" });

// Range query on a nested numeric field
db.products.find({ "attributes.price": { $lt: 50 } });

// Aggregation pipeline to unwind an array field
db.products.aggregate([
  { $unwind: "$attributes.tags" },
  { $group: { _id: "$attributes.tags", count: { $sum: 1 } } }
]);

Indexing nested fields is direct and doesn't require a generated-column workaround:

db.products.createIndex({ "attributes.wireless": 1 });
db.products.createIndex({ "attributes.tags": 1 }); // multikey index for array field

Choosing the Right Fit

PostgreSQL JSONB — best when most of your data is relational and structured, but a subset of columns genuinely vary in shape (product attributes, user preferences, webhook payloads). You get ACID transactions, joins, and JSON flexibility in the same engine.
MySQL JSON — a reasonable choice if you're already committed to MySQL and need occasional semi-structured storage, but expect to lean on generated columns for any field you query frequently at scale.
MongoDB — the right fit when the majority of your data is naturally document-shaped and doesn't fit a fixed relational schema well — content management, catalogs with wildly varying product attributes, event/activity logs.

A common anti-pattern worth naming: using a JSON/JSONB column as a way to avoid schema design entirely. If every row's JSON blob ends up needing the same five keys, those are columns, not JSON — a JSON column earns its place when the shape of the data genuinely varies row to row.

Summary

All three databases can store and query JSON, but the depth of support differs meaningfully. PostgreSQL JSONB offers the richest operator set and best indexing story for a relational database with JSON columns. MySQL JSON is functional but leans on generated columns for indexed lookups. MongoDB treats JSON-shaped documents as the native model, which is the right call when most of your schema is naturally semi-structured rather than the exception. Match the tool to how much of your data actually varies in shape, not to which JSON type sounds most modern.

Preparing a JSON payload to insert into one of these column types? JSON Formatter Hub validates and formats it entirely in your browser — free, no uploads.

JSON Patch and JSON Merge Patch — Partial Updates Without Sending Full Objects

Deepak Kumar — Fri, 28 Aug 2026 17:23:31 +0000

A common REST API mistake is requiring clients to send the entire resource just to change one field — update a user's email and you resend their name, address, and every other field unchanged. Two IETF standards solve this: JSON Patch (RFC 6902), which describes an ordered list of precise operations, and JSON Merge Patch (RFC 7396), which describes updates as a partial object to be merged. They solve overlapping problems differently, and picking the wrong one for your use case leads to real bugs — especially around deleting fields and updating arrays.

JSON Merge Patch (RFC 7396): Updates as a Partial Object

JSON Merge Patch is the simpler of the two. You send a JSON object containing only the fields you want to change, and the server merges it into the existing resource:

// Original resource
{
  "name": "Alice",
  "email": "alice@old.com",
  "role": "member",
  "address": { "city": "Boston", "zip": "02101" }
}

// Merge Patch — Content-Type: application/merge-patch+json
{
  "email": "alice@new.com"
}

// Result after merge
{
  "name": "Alice",
  "email": "alice@new.com",
  "role": "member",
  "address": { "city": "Boston", "zip": "02101" }
}

The merge algorithm is recursive for nested objects but replaces arrays wholesale — you cannot patch a single array element with Merge Patch, only replace the entire array. To delete a field, set its value to null in the patch:

// Merge Patch to remove the "role" field entirely
{ "role": null }

// Result
{
  "name": "Alice",
  "email": "alice@old.com",
  "address": { "city": "Boston", "zip": "02101" }
}

This null-means-delete rule is the single most important thing to remember about Merge Patch — and it's also its biggest limitation: if a field in your actual data model is legitimately supposed to hold the value null, Merge Patch cannot represent "set this field to null" versus "remove this field" as distinct operations. Both look identical on the wire.

JSON Patch (RFC 6902): An Ordered List of Operations

JSON Patch takes a different approach: instead of describing the end state, you describe the exact operations to apply, in order, using JSON Pointer (RFC 6901) paths to address specific locations:

// JSON Patch — Content-Type: application/json-patch+json
[
  { "op": "replace", "path": "/email", "value": "alice@new.com" },
  { "op": "remove", "path": "/role" },
  { "op": "add", "path": "/tags", "value": ["verified"] }
]

JSON Patch defines six operations:

add — inserts a value at the path; for an array index, inserts and shifts subsequent elements rather than overwriting
remove — deletes the value at the path (explicit, unambiguous — unlike Merge Patch's overloaded null)
replace — equivalent to a remove followed by an add at the same path
move — removes the value at from and adds it at path
copy — copies the value at from to path without removing the source
test — asserts the value at path equals the given value; the whole patch fails if the assertion doesn't hold — useful for optimistic-concurrency checks

Because operations target arrays by index with real insert/remove semantics, JSON Patch can express array edits that Merge Patch simply cannot:

// Original
{ "tags": ["draft", "internal"] }

// JSON Patch — insert "reviewed" at index 1, without touching the rest
[ { "op": "add", "path": "/tags/1", "value": "reviewed" } ]

// Result
{ "tags": ["draft", "reviewed", "internal"] }

The test operation is worth calling out specifically — it's how JSON Patch supports safe conditional updates without a separate ETag mechanism:

[
  { "op": "test", "path": "/role", "value": "member" },
  { "op": "replace", "path": "/role", "value": "admin" }
]
// If /role is not currently "member", the entire patch is rejected —
// protects against a lost-update race where the resource changed
// between when the client read it and when it sent the patch.

Merge Patch vs JSON Patch: Which One to Use

Aspect	JSON Merge Patch	JSON Patch
Format	Partial object	Array of operations
Complexity	Simple — easy to hand-write	More verbose, needs a library
Array edits	Replace whole array only	Insert/remove/move individual elements
Deleting a field	Set to `null` (ambiguous with real nulls)	Explicit `remove` op
Conditional updates	Not supported	`test` op for optimistic concurrency
Content-Type	`application/merge-patch+json`	`application/json-patch+json`

Use Merge Patch for typical "edit a form, submit changed fields" flows where your data model rarely stores meaningful null values and you never need surgical array edits. Use JSON Patch when you need precise array manipulation, explicit field removal that can't be confused with setting a null, or safe concurrent updates via test.

Implementing PATCH in a REST API

Both formats are delivered via HTTP PATCH (not PUT, which implies full replacement), distinguished by Content-Type. A minimal Node.js/Express handler for Merge Patch looks like:

const mergePatch = require('json-merge-patch');

app.patch('/users/:id', express.json({ type: 'application/merge-patch+json' }), (req, res) => {
  const existing = getUser(req.params.id);
  const updated = mergePatch.apply(existing, req.body);
  saveUser(req.params.id, updated);
  res.json(updated);
});

And for JSON Patch, using the fast-json-patch library:

const jsonpatch = require('fast-json-patch');

app.patch('/users/:id', express.json({ type: 'application/json-patch+json' }), (req, res) => {
  const existing = getUser(req.params.id);
  const result = jsonpatch.applyPatch(existing, req.body);
  saveUser(req.params.id, result.newDocument);
  res.json(result.newDocument);
});

In both cases, validate the patch against your resource's JSON Schema after applying it — a syntactically valid patch can still produce an object that violates your business rules (an add that introduces an unexpected field, a replace that sets a string field to an invalid enum value).

Summary

JSON Merge Patch and JSON Patch both let clients send only what changed instead of a full resource, but they're not interchangeable. Merge Patch is simpler and fine for flat, form-like updates; JSON Patch is more expressive, supports precise array operations and explicit field removal, and adds optimistic-concurrency control via test. Pick based on whether your updates ever need surgical array edits or safe conditional application — if not, Merge Patch's simplicity usually wins.

Comparing a resource before and after a patch is applied? JSON Formatter Hub's Compare tool shows exactly what changed, entirely in your browser.

How to Convert JSON to CSV, XML, and YAML (With Examples)

Deepak Kumar — Fri, 28 Aug 2026 16:51:43 +0000

JSON is the universal interchange format, but that doesn't mean every tool that needs your data speaks JSON. Spreadsheet users want CSV. Enterprise integrations often expect XML. Infrastructure engineers configure in YAML. Knowing how to convert JSON to each format — and the traps to avoid along the way — is a daily developer skill.

Contents: JSON to CSV · JSON to XML · JSON to YAML · Which Format to Choose

1. JSON to CSV

CSV works naturally for flat arrays of objects — each object becomes a row, each key becomes a column header. The difficulty arises with nested objects and arrays.

The source JSON:

[
  { "id": 1, "name": "Alice", "email": "alice@example.com", "score": 98.5, "active": true },
  { "id": 2, "name": "Bob", "email": "bob@example.com", "score": 87.0, "active": false }
]

Target CSV:

id,name,email,score,active
1,Alice,alice@example.com,98.5,true
2,Bob,bob@example.com,87,false

JavaScript — JSON to CSV:

function jsonToCsv(jsonArray) {
  if (!Array.isArray(jsonArray) || jsonArray.length === 0) {
    throw new Error('Input must be a non-empty array');
  }

  // Collect all unique keys across all objects (handles sparse data)
  const headers = [...new Set(jsonArray.flatMap(obj => Object.keys(obj)))];

  const escape = (value) => {
    if (value === null || value === undefined) return '';
    const str = String(value);
    // Wrap in quotes if contains comma, quote, or newline
    if (str.includes(',') || str.includes('"') || str.includes('\n')) {
      return '"' + str.replace(/"/g, '""') + '"';
    }
    return str;
  };

  const rows = jsonArray.map(obj =>
    headers.map(h => escape(obj[h])).join(',')
  );

  return [headers.join(','), ...rows].join('\n');
}

// Usage
const data = JSON.parse(jsonString);
const csv = jsonToCsv(data);

// Download in browser
const blob = new Blob([csv], { type: 'text/csv' });
const url = URL.createObjectURL(blob);
const a = document.createElement('a');
a.href = url;
a.download = 'data.csv';
a.click();

Python — JSON to CSV:

import csv
import json
import io

def json_to_csv(json_data: list[dict]) -> str:
    if not json_data:
        return ''

    # Collect all keys to handle sparse objects
    all_keys = list(dict.fromkeys(
        key for obj in json_data for key in obj.keys()
    ))

    output = io.StringIO()
    writer = csv.DictWriter(
        output,
        fieldnames=all_keys,
        extrasaction='ignore',
        restval=''  # value for missing fields
    )
    writer.writeheader()
    writer.writerows(json_data)
    return output.getvalue()

# Usage
with open('data.json') as f:
    data = json.load(f)

csv_text = json_to_csv(data)

with open('output.csv', 'w', newline='', encoding='utf-8') as f:
    f.write(csv_text)

Flattening nested JSON for CSV. CSV has no concept of nested structure. If your JSON objects contain nested objects or arrays, you must decide how to flatten them.

// Source: nested JSON
{
  "id": 1,
  "name": "Alice",
  "address": { "city": "London", "country": "UK" },
  "tags": ["admin", "editor"]
}

// After flattening (dot-notation keys for nested objects, joined for arrays)
{
  "id": 1,
  "name": "Alice",
  "address.city": "London",
  "address.country": "UK",
  "tags": "admin|editor"
}

// JavaScript flatten function
function flattenObject(obj, prefix = '') {
  return Object.keys(obj).reduce((acc, key) => {
    const fullKey = prefix ? `${prefix}.${key}` : key;
    const value = obj[key];

    if (value !== null && typeof value === 'object' && !Array.isArray(value)) {
      Object.assign(acc, flattenObject(value, fullKey));
    } else if (Array.isArray(value)) {
      acc[fullKey] = value.join('|'); // or JSON.stringify(value)
    } else {
      acc[fullKey] = value;
    }
    return acc;
  }, {});
}

const flattened = data.map(obj => flattenObject(obj));
const csv = jsonToCsv(flattened);

CSV gotchas:

Commas in values — must be wrapped in double quotes: "London, UK"
Quotes inside quoted values — escaped by doubling: "He said ""hello"""
Newlines in values — wrap the entire value in quotes
Boolean and null — CSV has no native types; true, false, and empty string are all strings in the output
Line endings — use \r\n (CRLF) for maximum compatibility with Excel on Windows

2. JSON to XML

XML is more expressive than JSON in some ways (attributes vs. elements, namespaces, comments) but the mapping from JSON to XML is lossy — you have to make decisions about how to represent each JSON type.

The mapping rules:

JSON	XML Representation
Object `{"key": "val"}`	`<key>val</key>`
Array `[1, 2, 3]`	Repeated `<item>` elements
String	Text node content
Number	Text node content
Boolean	Text node: `true` or `false`
`null`	`<key xsi:nil="true" />` or empty element

Example conversion:

{
  "user": {
    "id": 42,
    "name": "Alice",
    "roles": ["admin", "editor"],
    "address": { "city": "London", "country": "UK" }
  }
}

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <user>
    <id>42</id>
    <name>Alice</name>
    <roles>
      <item>admin</item>
      <item>editor</item>
    </roles>
    <address>
      <city>London</city>
      <country>UK</country>
    </address>
  </user>
</root>

JavaScript — JSON to XML:

function jsonToXml(obj, rootElement = 'root', indent = 0) {
  const pad = '  '.repeat(indent);

  if (obj === null) return `${pad}<${rootElement}/>`;
  if (typeof obj !== 'object') {
    return `${pad}<${rootElement}>${escapeXml(String(obj))}</${rootElement}>`;
  }

  if (Array.isArray(obj)) {
    return obj.map(item => jsonToXml(item, 'item', indent)).join('\n');
  }

  const children = Object.entries(obj)
    .map(([key, val]) => jsonToXml(val, key, indent + 1))
    .join('\n');

  return `${pad}<${rootElement}>\n${children}\n${pad}</${rootElement}>`;
}

function escapeXml(str) {
  return str
    .replace(/&/g, '&amp;')
    .replace(/</g, '&lt;')
    .replace(/>/g, '&gt;')
    .replace(/"/g, '&quot;')
    .replace(/'/g, '&apos;');
}

const xml = '<?xml version="1.0" encoding="UTF-8"?>\n' +
  jsonToXml(JSON.parse(jsonString), 'root');

Python — JSON to XML:

import json
import xml.etree.ElementTree as ET

def dict_to_xml(data, parent):
    if isinstance(data, dict):
        for key, value in data.items():
            child = ET.SubElement(parent, key)
            dict_to_xml(value, child)
    elif isinstance(data, list):
        for item in data:
            child = ET.SubElement(parent, 'item')
            dict_to_xml(item, child)
    elif data is None:
        parent.set('xsi:nil', 'true')
    else:
        parent.text = str(data)

def json_to_xml(json_str: str, root_tag: str = 'root') -> str:
    data = json.loads(json_str)
    root = ET.Element(root_tag)
    dict_to_xml(data, root)
    ET.indent(root, space='  ')  # Python 3.9+
    return ET.tostring(root, encoding='unicode', xml_declaration=True)

xml_output = json_to_xml(open('data.json').read())

XML gotchas:

XML element names can't start with numbers. A JSON key like "1stItem" becomes an invalid XML tag — you'll need to prefix it (<item_1stItem>) or sanitize keys.
XML element names can't contain spaces. JSON keys with spaces must be converted (e.g., replace with underscores).
Special characters must be escaped: & → &, < → <, > → >
Array element naming is ambiguous. When a JSON array contains objects, what do you name each element? Convention: use the singular form of the parent key or <item>.

3. JSON to YAML

JSON is a strict subset of YAML — every valid JSON document is also valid YAML. Converting from JSON to YAML is about readability: YAML drops the quotes, braces, and brackets of JSON in favor of indentation-based structure.

Side-by-side comparison:

{
  "server": {
    "host": "localhost",
    "port": 8080,
    "debug": true,
    "allowed_hosts": ["example.com", "api.example.com"]
  }
}

server:
  host: localhost
  port: 8080
  debug: true
  allowed_hosts:
    - example.com
    - api.example.com

JavaScript — JSON to YAML. Use the js-yaml library — converting YAML by hand is error-prone.

// npm install js-yaml
const yaml = require('js-yaml');
const fs = require('fs');

const data = JSON.parse(fs.readFileSync('data.json', 'utf8'));
const yamlStr = yaml.dump(data, {
  indent: 2,
  lineWidth: -1,  // disable line wrapping
  noRefs: true    // don't use YAML aliases for repeated values
});

fs.writeFileSync('output.yaml', yamlStr);

Python — JSON to YAML:

# pip install pyyaml
import json
import yaml

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

with open('output.yaml', 'w') as f:
    yaml.dump(
        data,
        f,
        default_flow_style=False,  # block style, not inline
        allow_unicode=True,
        sort_keys=False  # preserve key order
    )

YAML gotchas when converting from JSON:

The Norway problem (YAML 1.1):

# YAML 1.1 interprets these as booleans, not strings:
country: NO   # parsed as false in YAML 1.1
flag: yes     # parsed as true
status: on    # parsed as true

# In JSON, these would have been quoted strings: "NO", "yes", "on"
# Fix: always quote ambiguous string values, or use YAML 1.2

Octal number ambiguity:

# YAML 1.1 interprets leading zeros as octal:
permissions: 0755  # becomes integer 493 in YAML 1.1!

# Fix: quote it
permissions: "0755"

Multiline strings:

# Long strings in JSON: {"description": "Line one\nLine two\nLine three"}

# YAML literal block scalar (preserves newlines):
description: |
  Line one
  Line two
  Line three

# YAML folded scalar (newlines become spaces):
description: >
  Line one
  Line two
  Line three

Anchors and aliases (YAML-only feature). When converting from JSON to YAML, you lose the ability to use YAML anchors (&anchor) and aliases (*alias) to deduplicate repeated values — those are written by hand or added by YAML-aware serializers. The conversion will duplicate the data.

Validating your YAML output. Always parse the YAML output back to verify it round-trips correctly:

import json
import yaml

original = json.loads(original_json)
converted = yaml.safe_load(yaml_output)

assert original == converted, "Round-trip failed!"

4. Which Format to Choose

Use Case	Best Format	Reason
Spreadsheet analysis, Excel, Google Sheets	CSV	Native import; no programming required
Flat tabular data export	CSV	Smallest file size, widest tool support
Enterprise integrations, SOAP services	XML	Schema validation (XSD), namespace support
Document stores, content with mixed structure	XML	Mixed content model (text + elements)
Kubernetes / Docker Compose config	YAML	Ecosystem standard
CI/CD pipelines (GitHub Actions, GitLab CI)	YAML	Ecosystem standard
Config files developers will hand-edit	YAML	Comments, readability, less syntax noise
API responses, web data transfer	JSON	Native browser support, fast parsing
Deeply nested hierarchical data	JSON or XML	CSV cannot represent nesting

Quick reference — format capabilities:

Feature	JSON	CSV	XML	YAML
Nested structure	Yes	No	Yes	Yes
Arrays	Yes	No (workaround)	Yes	Yes
Comments	No	No	Yes	Yes
Schema validation	JSON Schema	No standard	XSD, DTD	No standard
Human-editable	Moderate	Yes (simple)	Verbose	Yes
Spreadsheet import	Manual	Native	Manual	Manual
Browser native	Yes	No	Yes (DOM)	No
Null values	`null`	Empty string	`xsi:nil`	`null` or `~`

Converting in the browser? JSON Formatter Hub's Export button converts JSON to CSV, XML, and YAML directly client-side — no data sent to a server, using the same logic shown in this article.

JSON5 — The Relaxed JSON Format That Allows Comments and Trailing Commas

Deepak Kumar — Fri, 28 Aug 2026 16:46:59 +0000

Strict JSON is deliberately minimal — no comments, no trailing commas, quoted keys only. That minimalism makes it an excellent wire format, but a frustrating one to hand-edit. JSON5 is a community-driven superset of JSON that relaxes exactly those restrictions, aimed squarely at files humans write and maintain by hand: configuration files, build manifests, and data humans read.

What JSON5 Adds on Top of JSON

JSON5 is a strict superset — every valid JSON document is also valid JSON5. It adds:

Comments — both // single-line and /* */ block comments
Trailing commas — in objects and arrays, so diffs stay clean when you add a line
Unquoted object keys — as long as they're valid JavaScript identifiers
Single-quoted strings — in addition to double-quoted
Multi-line strings — using a backslash line continuation
Extra numeric forms — leading/trailing decimal points, hexadecimal, Infinity, NaN, and a leading + sign

Here's the same configuration written first as strict JSON, then as JSON5:

// Strict JSON — no comments allowed, this is illustrative only
{
  "name": "my-app",
  "port": 8080,
  "features": ["auth", "logging"],
  "debug": false
}

// JSON5 — comments and trailing commas are fine
{
  // Server configuration
  name: 'my-app',
  port: 8080,
  features: [
    'auth',
    'logging', // trailing comma is OK
  ],
  debug: false, // also OK here
}

The JSON5 version is shorter to type, easier to diff in version control (trailing commas mean adding a line doesn't touch the line above it), and self-documenting via comments — none of which strict JSON supports.

Where JSON5 Is Actually Used

JSON5 rarely appears on the wire between client and server — strict JSON remains the standard for APIs. Its real home is configuration:

Babel accepts .babelrc as JSON5 as well as strict JSON
ESLint config files support JSON5-style comments
VS Code's settings.json and tasks.json use a JSON-with-comments variant in the same spirit
WebStorm/IntelliJ run configurations and various build tool manifests

The pattern is consistent: any file a human is expected to open, read, and edit by hand is a good JSON5 candidate. Any file exchanged purely between programs should stay as strict JSON, because strict JSON has near-universal, zero-ambiguity parser support.

Parsing JSON5 in Node.js

Node's built-in JSON.parse only accepts strict JSON — comments and trailing commas throw a SyntaxError. Use the json5 npm package instead:

npm install json5

const JSON5 = require('json5');
const fs = require('fs');

const raw = fs.readFileSync('config.json5', 'utf8');
const config = JSON5.parse(raw);

console.log(config.name); // 'my-app'

// JSON5 can also stringify back out, optionally without quoting keys
const text = JSON5.stringify(config, null, 2);

The API deliberately mirrors the built-in JSON object (JSON5.parse, JSON5.stringify), so swapping strict JSON parsing for JSON5 parsing in an existing codebase is usually a one-line change.

Parsing JSON5 in Python

Python's standard library json module is strict as well. The json5 PyPI package fills the same gap:

pip install json5

import json5

with open('config.json5') as f:
    config = json5.load(f)

print(config['name'])  # 'my-app'

An alternative worth knowing about: Python's own json module already tolerates some non-strict input if you pass parse_constant, but it does not support comments or trailing commas — for those you still need the dedicated json5 package.

JSON5 vs YAML vs TOML for Config Files

JSON5 isn't the only human-friendly config format. Here's how the three most common options compare:

JSON5 — closest to JSON, easiest to generate programmatically and to parse with existing JSON-shaped tooling, but less readable for deeply nested structures than YAML
YAML — most human-readable for deep nesting, supports comments and anchors/references, but whitespace-sensitivity is a common source of subtle bugs
TOML — favored by Rust (Cargo.toml) and Python (pyproject.toml) tooling, explicit and unambiguous, but more verbose for deeply nested data

If your project's config already round-trips through JSON elsewhere (build tools, IDE integrations, JSON Schema validation), JSON5 is usually the path of least resistance since your existing JSON tooling largely still applies. If deep nesting and human authorship are the priority, YAML tends to win.

Things to Watch Out For

JSON5's flexibility comes with a few sharp edges:

Not a wire format — don't send JSON5 over HTTP APIs; strict JSON is universally supported, JSON5 parsers are not guaranteed to exist on the receiving end
Unquoted keys follow JS identifier rules — a key like "content-type" (with a hyphen) still needs quotes
NaN and Infinity aren't valid JSON — if you round-trip a JSON5 file that uses them through a strict JSON parser elsewhere in your pipeline, it will fail
Tooling support varies — always confirm the specific library or CLI tool you're feeding a JSON5 file into actually documents JSON5 support, rather than assuming a lenient JSON parser handles the full spec

Summary

JSON5 keeps JSON's simple, JavaScript-object-literal-like structure while removing the friction of hand-editing: comments explain intent, trailing commas keep diffs clean, and unquoted keys reduce visual noise. It's the right choice for configuration files that developers read and edit directly — Babel configs, build manifests, editor settings — but it should stay out of your network API responses, where strict JSON remains the universal, unambiguous standard.

Need to convert a JSON5 config down to strict JSON, or just validate the underlying structure? JSON Formatter Hub formats and validates entirely in your browser — free, no uploads (strip comments and trailing commas first, since it validates strict JSON).

JSON vs YAML — Key Differences and When to Use Each

Deepak Kumar — Fri, 28 Aug 2026 11:44:34 +0000

JSON and YAML are both text-based formats for representing structured data, and both appear constantly in modern software development. JSON dominates REST APIs and browser applications; YAML dominates CI/CD pipelines, Kubernetes, and configuration files. Understanding the trade-offs helps you pick the right format and avoid the surprising pitfalls each one carries.

Side-by-Side Syntax Comparison

The same application configuration written in both formats:

JSON:

{
  "app": "my-service",
  "version": "2.1.0",
  "server": {
    "host": "0.0.0.0",
    "port": 8080,
    "debug": false
  },
  "database": {
    "host": "db.example.com",
    "ssl": true
  },
  "allowedOrigins": [
    "https://app.example.com",
    "https://www.example.com"
  ],
  "description": "Main API service"
}

YAML:

# Application configuration
app: my-service
version: "2.1.0"
server:
  host: "0.0.0.0"
  port: 8080
  debug: false
database:
  host: db.example.com
  ssl: true
allowedOrigins:
  - https://app.example.com
  - https://www.example.com
description: Main API service

YAML is visibly less noisy — no braces, fewer quotes, and comments are allowed. JSON is more explicit about every boundary.

YAML Advantages

Comments. YAML supports # comments. JSON does not. This is the most practically important difference for config files that humans edit:

# Database settings — update host before deploying to production
database:
  host: db.prod.example.com  # change this for staging
  port: 5432

Multi-line strings. YAML has two block scalar styles. The literal block (|) preserves newlines; the folded block (>) folds them into spaces:

message: |
  Dear user,
  Your account has been created.
  Welcome aboard!

summary: >
  This text spans multiple
  lines but will be joined
  into a single line.

Anchors and aliases (DRY config). YAML lets you define a block once and reuse it with & and *:

defaults: &defaults
  retries: 3
  timeout: 30

production:
  <<: *defaults
  host: prod.example.com

staging:
  <<: *defaults
  host: staging.example.com

JSON Advantages

Strict syntax — fewer surprises. JSON has one way to write every value. YAML has many, and they interact unexpectedly. JSON parse errors are rare after learning the four rules (double quotes, no trailing commas, no comments, no unquoted keys). YAML parse errors are often invisible — the parser accepts the file but silently produces the wrong value.

Universal browser and API support. Every browser supports JSON.parse() natively. Every REST framework defaults to JSON. YAML requires a library in virtually every language. For HTTP APIs, configuration-as-code that runs in the browser, and database documents, JSON is the practical default.

Faster to parse. JSON parsers are highly optimized because the format is so simple. YAML parsers must handle indentation sensitivity, implicit type coercion, multiple quoting styles, anchors, and more — making them slower and harder to implement correctly.

YAML Gotchas You Must Know

The Norway problem (implicit boolean coercion). In YAML 1.1 (used by many tools including older Kubernetes versions), unquoted country codes like NO, yes, on, off are parsed as booleans. NO becomes false. This breaks locale codes, toggle names, and short keys silently:

# Dangerous in YAML 1.1
countries:
  - NO   # parsed as false, not the string "NO"
  - GB
  - US

# Safe: always quote ambiguous values
countries:
  - "NO"
  - GB
  - US

Indentation is structural. A single wrong indent level moves a key to the wrong parent object. JSON uses braces, so indentation is cosmetic. In YAML it is syntax:

# WRONG — logging is a sibling of server, not a child
server:
  host: localhost
logging:      # intended to be under server
  level: debug

# CORRECT
server:
  host: localhost
  logging:
    level: debug

Strings that look like other types. Unquoted values are type-coerced. Version numbers, port numbers written as strings, and other values can be misinterpreted:

version: 1.10    # parsed as float 1.1, not string "1.10"
version: "1.10"  # correct — string preserved

port: 8080       # fine — integer
country: NO      # problem — boolean false in YAML 1.1

Where Each Format Wins

Use Case	Best Choice	Why
REST API response	JSON	Native browser support, universal client expectation
Kubernetes manifests	YAML	Less verbose, comments, official format for K8s
GitHub Actions workflow	YAML	Multiline scripts, comments, official format
Docker Compose	YAML	Anchors for shared config, readability
`package.json` / `tsconfig.json`	JSON	Node.js tooling expects JSON
Database documents	JSON	MongoDB, Firestore, DynamoDB use JSON natively
Human-edited app config	YAML	Comments explain intent; less punctuation to misplace
Machine-generated config	JSON	Easier to generate correctly; no indentation to manage

YAML Is a JSON Superset (With Caveats)

The YAML 1.2 specification states that JSON is valid YAML. In practice, most YAML parsers accept valid JSON. This means you can gradually migrate a JSON config to YAML by renaming it and adding comments without changing any values. However, don't rely on this in production without testing — older YAML 1.1 parsers have edge cases where valid JSON is rejected.

Quick Decision Guide

Writing a REST API? Use JSON.
Writing a CI/CD pipeline (GitHub Actions, GitLab CI, CircleCI)? Use YAML.
Writing Kubernetes or Helm charts? Use YAML.
Writing a config file that humans edit frequently and need to annotate? Use YAML.
Generating config programmatically from code? JSON is safer to generate correctly.
Storing data in a database or sending over HTTP? JSON.

Converting Between JSON and YAML

Since YAML 1.2 is a superset of JSON, most YAML parsers can read valid JSON directly. Going the other way — YAML to JSON — requires a YAML parser and a JSON serializer.

Python — bidirectional conversion:

import json
import yaml  # pip install pyyaml

# 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, allow_unicode=True)

# YAML → JSON
with open('config.yaml') as f:
    data = yaml.safe_load(f)
with open('config.json', 'w') as f:
    json.dump(data, f, indent=2)

Node.js — bidirectional conversion:

const fs = require('fs');
const yaml = require('js-yaml'); // npm install js-yaml

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

// YAML → JSON
const loaded = yaml.load(fs.readFileSync('config.yaml', 'utf8'));
fs.writeFileSync('config.json', JSON.stringify(loaded, null, 2));

Command line with yq:

# JSON → YAML
yq -o=yaml config.json > config.yaml

# YAML → JSON
yq -o=json config.yaml > config.json

# Query YAML (like jq for YAML)
yq '.server.port' config.yaml

Linting and Validation

Both formats benefit from automated checks in CI/CD pipelines to catch syntax errors before they reach production.

JSON linting:

jq — jq . file.json > /dev/null exits with a non-zero code if the file is invalid JSON. Simple and fast.
JSON Schema — validates not just syntax but structure and data types.
ESLint — for JavaScript projects, can flag invalid inline JSON and enforce JSON.parse error handling.

YAML linting:

yamllint — pip install yamllint, then yamllint config.yaml. Catches indentation issues, duplicate keys, and trailing spaces.
kubeval / kubeconform — validates Kubernetes YAML manifests against the official schema. Catches wrong field names and types before kubectl apply.
GitHub Actions schema validation — the official VS Code YAML extension can validate workflow files against the GitHub Actions JSON Schema automatically.

TOML: A Third Option Worth Knowing

TOML (Tom's Obvious Minimal Language) is increasingly common for developer tooling configuration — Rust's Cargo.toml, Python's pyproject.toml, and Hugo static site configs use it. TOML is more opinionated than YAML (no implicit types, strict date handling) and more readable than JSON for config files with many sections. It's not suitable for data exchange or APIs — only for configuration. If you see a .toml file, it occupies a niche between JSON's strictness and YAML's readability.

Need to format, validate, or fix JSON right now? JSON Formatter Hub does it entirely in your browser — free, no uploads.

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

JSON in Databases — PostgreSQL JSONB, MySQL JSON, and MongoDB

PostgreSQL: JSON vs JSONB

MySQL: The JSON Column Type

MongoDB: JSON as the Native Model

Choosing the Right Fit

Summary

JSON Patch and JSON Merge Patch — Partial Updates Without Sending Full Objects

JSON Merge Patch (RFC 7396): Updates as a Partial Object

JSON Patch (RFC 6902): An Ordered List of Operations

Merge Patch vs JSON Patch: Which One to Use

Implementing PATCH in a REST API

Summary

How to Convert JSON to CSV, XML, and YAML (With Examples)

1. JSON to CSV

2. JSON to XML

3. JSON to YAML

4. Which Format to Choose

JSON5 — The Relaxed JSON Format That Allows Comments and Trailing Commas

What JSON5 Adds on Top of JSON

Where JSON5 Is Actually Used

Parsing JSON5 in Node.js

Parsing JSON5 in Python

JSON5 vs YAML vs TOML for Config Files

Things to Watch Out For

Summary

JSON vs YAML — Key Differences and When to Use Each

Side-by-Side Syntax Comparison

YAML Advantages

JSON Advantages

YAML Gotchas You Must Know

Where Each Format Wins

YAML Is a JSON Superset (With Caveats)

Quick Decision Guide

Converting Between JSON and YAML

Linting and Validation

TOML: A Third Option Worth Knowing

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

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