DEV Community: 99Tools

A practical guide to CSS gradients beyond the basics — angles explained properly, repeating patterns, fixing the "muddy middle" with oklch interpolation, real gradient animation with @property, and mesh gradients. Code examples throughout.

99Tools — Mon, 21 Sep 2026 14:17:13 +0000

99Tools

Sep 21

CSS Gradients: The Complete Guide

#css #frontend #tutorial #webdev

6 min read

CSS Gradients: The Complete Guide

99Tools — Mon, 21 Sep 2026 14:15:19 +0000

You know the moment. You're building a hero section, you drop in linear-gradient(to right, #667eea, #764ba2), and it looks... fine. Then you spend the next twenty minutes nudging hex values because the middle of the gradient has turned a weird muddy gray, and you're not totally sure why.

That muddy-middle problem, plus a handful of other things most gradient tutorials skip, is what this post is actually about. Linear and radial gradients are the 20% everyone learns. This covers the other 80% — repeating patterns, color-space interpolation, proper gradient animation, mesh gradients, and the small details that separate "it works" from "it looks intentional."

The three gradient types, at a glance

Type	What it does	Best for
`linear-gradient()`	Transitions colors along a straight line	Hero backgrounds, buttons, overlays
`radial-gradient()`	Radiates colors from a center point	Spotlights, glows, vignettes
`conic-gradient()`	Sweeps colors around a center point	Pie charts, color wheels, loading spinners

All three are treated as CSS images, which means anywhere background-image is valid, a gradient is valid too — including layered on top of real photos.

Linear gradients: the angle math nobody explains

.hero {
  background: linear-gradient(to right, #ff6b6b, #4ecdc4);
}

You can direct a linear gradient with a keyword (to right, to bottom left) or a specific angle:

background: linear-gradient(45deg, #ff6b6b, #4ecdc4);

Here's the part that trips people up: 0deg points up, not right. Angles increase clockwise from there — 90deg is left-to-right, 180deg is top-to-bottom. If you've ever plugged in a "logical" angle and gotten the wrong direction, this is why.

Multiple color stops

.sunset {
  background: linear-gradient(
    to bottom,
    #ff9a56 0%,
    #ff6b6b 30%,
    #c44569 60%,
    #3d1e6d 100%
  );
}

The percentages control exactly where each color hits full intensity — this is how you get more control than an even, evenly-spaced blend.

Hard stops (no blending)

Place two colors at the same percentage and you get a hard edge instead of a gradient — this is how diagonal stripe patterns are built without a single image file:

.stripes {
  background: linear-gradient(
    45deg,
    #667eea 25%, #764ba2 25%,
    #764ba2 50%, #667eea 50%,
    #667eea 75%, #764ba2 75%
  );
  background-size: 40px 40px;
}

Radial gradients

.spotlight {
  background: radial-gradient(circle, #ffeaa7, #2d3436);
}

You control shape (circle / ellipse), size, and position:

.glow {
  background: radial-gradient(
    circle at top left,
    rgba(255, 255, 255, 0.3),
    transparent 60%
  );
}

at top left repositions the center — useful for faking a light source hitting a card from one corner.

Conic gradients

The newest of the three, and underused. Colors sweep around a center point like a pie chart:

.pie-chart {
  background: conic-gradient(
    #ff6b6b 0deg 90deg,
    #4ecdc4 90deg 180deg,
    #ffeaa7 180deg 270deg,
    #a29bfe 270deg 360deg
  );
  border-radius: 50%;
}

That's a working pie chart with zero canvas or SVG. Most pure-CSS loading spinners and color-wheel pickers are conic gradients under the hood.

Repeating gradients (the part most tutorials skip)

All three gradient types have a repeating counterpart: repeating-linear-gradient(), repeating-radial-gradient(), and repeating-conic-gradient(). Instead of stretching a gradient once across an element, it tiles the pattern to fill the space.

/* Checkerboard-style stripes */
.repeating-stripes {
  background: repeating-linear-gradient(
    45deg,
    #667eea 0px,
    #667eea 10px,
    #764ba2 10px,
    #764ba2 20px
  );
}

/* Concentric rings */
.target {
  background: repeating-radial-gradient(
    circle,
    #ff6b6b 0px,
    #ff6b6b 10px,
    #ffffff 10px,
    #ffffff 20px
  );
}

/* Pie-slice loading spinner */
.spinner {
  background: repeating-conic-gradient(
    #667eea 0deg 10deg,
    transparent 10deg 20deg
  );
  border-radius: 50%;
}

This is the technique behind most CSS-only progress rings, barcode-style patterns, and textured backgrounds — no repeated background image, no extra HTTP request.

Transparency: fading into nothing

Gradients don't need two solid endpoints — they can fade into full transparency, which is how readable text-over-image overlays get built:

.image-overlay {
  background: linear-gradient(
    to bottom,
    transparent 0%,
    rgba(0, 0, 0, 0.8) 100%
  );
}

Fixing the "muddy middle" problem: color-space interpolation

Remember the hero section from the intro? Here's what's actually happening. By default, browsers interpolate gradient colors in the sRGB color space, which produces desaturated, grayish midpoints — especially between colors that sit far apart on the color wheel, like blue and yellow.

Modern CSS lets you pick a different interpolation space:

/* Default sRGB — can look muddy in the middle */
.old-way {
  background: linear-gradient(90deg, #3b82f6, #eab308);
}

/* OKLCH interpolation — smoother, more vivid transition */
.new-way {
  background: linear-gradient(in oklch, 90deg, #3b82f6, #eab308);
}

oklch interpolates through a perceptually uniform color space, so the midpoint stays vivid instead of collapsing into gray. This single change is one of the most underrated gradient upgrades available right now — worth testing on any gradient that's looked slightly "off" without an obvious reason. It's well supported across current Chrome, Firefox, and Safari; the only thing to check is whether your project still needs to support noticeably older browser versions.

Gradient text

.gradient-text {
  background: linear-gradient(90deg, #667eea, #764ba2);
  -webkit-background-clip: text;
  background-clip: text;
  color: transparent;
}

background-clip: text uses the text glyphs as a mask, letting the gradient show through the letter shapes instead of filling as a solid color.

Gradient borders

Borders don't accept background directly, so this uses a layered-background workaround:

.gradient-border {
  border: 4px solid transparent;
  border-radius: 12px;
  background:
    linear-gradient(white, white) padding-box,
    linear-gradient(45deg, #667eea, #764ba2) border-box;
}

One gradient fills the interior, the other fills just the border area — a genuinely elegant use of layered backgrounds.

Animating gradients, properly

The classic trick oversizes the gradient and animates its position:

.animated-gradient {
  background: linear-gradient(270deg, #ff6b6b, #4ecdc4, #ffeaa7, #a29bfe);
  background-size: 800% 800%;
  animation: gradientShift 8s ease infinite;
}

@keyframes gradientShift {
  0% { background-position: 0% 50%; }
  50% { background-position: 100% 50%; }
  100% { background-position: 0% 50%; }
}

This works, but it's animating the position, not the gradient itself. Browsers can't natively interpolate between two arbitrary gradient definitions — which is why this workaround exists at all.

There's a more direct approach now: register the angle as a custom property with @property, which makes it genuinely animatable.

@property --angle {
  syntax: '<angle>';
  initial-value: 0deg;
  inherits: false;
}

.rotating-gradient {
  background: linear-gradient(var(--angle), #ff6b6b, #4ecdc4);
  animation: rotate 4s linear infinite;
}

@keyframes rotate {
  to { --angle: 360deg; }
}

This actually rotates the gradient's angle frame by frame, rather than sliding a zoomed-in gradient around. @property is now well supported across current Chrome, Firefox, and Safari — if you're targeting older browser versions specifically, it's still worth a quick check, but for most projects today it's safe to ship as-is.

Mesh gradients

That soft, blurry, multi-color blob look you've been seeing on SaaS landing pages lately isn't a new CSS feature — it's just several radial gradients layered on top of each other:

.mesh-gradient {
  background-color: #1a1a2e;
  background-image:
    radial-gradient(at 20% 20%, rgba(255, 107, 107, 0.6) 0px, transparent 50%),
    radial-gradient(at 80% 0%, rgba(78, 205, 196, 0.5) 0px, transparent 50%),
    radial-gradient(at 0% 100%, rgba(162, 155, 254, 0.5) 0px, transparent 50%),
    radial-gradient(at 80% 100%, rgba(255, 234, 167, 0.4) 0px, transparent 50%);
}

Each radial gradient acts like a soft colored light source; stacking a few at different positions and opacities produces that trendy, organic blend. No image assets, no canvas — just layered backgrounds.

Practical checklist before you ship a gradient

Contrast: if you're doing gradient text or a gradient button, check contrast at both ends of the gradient, not just the midpoint. A gradient readable at 20% but not at 80% will still fail an accessibility audit.
Dark mode: a gradient tuned for light mode often looks muddy in dark mode. Define separate gradient variables per theme if your site supports both.
Performance: gradients are cheap — no HTTP request, no image decode. If you're using a background image purely for a color wash, a gradient is almost always the better call.
Browser support: linear, radial, and conic gradients, in oklch interpolation, and @property-based animation are all well supported in current Chrome, Firefox, and Safari. If your project needs to support noticeably older browser versions, caniuse.com is the fastest way to double-check a specific feature.

Wrapping up

Gradients reward going one level past the basics. Understanding angles properly, knowing when interpolation is making your colors muddy, and having repeating and conic gradients in your toolkit means you can replace a surprising number of image assets with a few lines of CSS — lighter pages, and effects that are trivial to tweak later without touching a design tool.

If you'd rather compose a gradient visually before writing the CSS by hand — dragging stops, adjusting the angle, previewing oklch vs. sRGB — that's a workflow a visual gradient builder handles well; this one is one option if you want to skip the manual math.

For the full technical reference on interpolation and gradient syntax, MDN's gradient documentation is the best place to go deeper.

What's the trickiest gradient effect you've had to build? Curious what's tripped other people up.

CSV to JSON looks easy until BOMs, leading zeros, quoted commas, and ragged rows show up. Tested Python & Node code for the edge cases that actually break production scripts.

99Tools — Tue, 15 Sep 2026 05:15:13 +0000

99Tools

Sep 15

CSV to JSON: The Parts Nobody Mentions Until Your Script Breaks in Production

#csv #json #python #javascript

9 min read

CSV to JSON: The Parts Nobody Mentions Until Your Script Breaks in Production

99Tools — Tue, 15 Sep 2026 05:13:15 +0000

If you've ever written line.split(',') to parse a CSV file, you already know how this story ends. It works great on your test file, ships to production, and then someone opens the export in Excel, types a comma into a "Notes" field, saves it, and your parser quietly shifts every column after that one.

CSV to JSON conversion looks like a five-minute task right up until it isn't. This post walks through what actually goes wrong, how to handle it properly, and where the effort is or isn't worth it — whether you're writing a one-off script or building something that has to survive contact with real-world data.

Why "just split on commas" doesn't work

CSV (Comma-Separated Values) is a deceptively simple-looking format with a genuinely messy specification (RFC 4180, if you want to read it, though half the CSVs in the wild don't fully follow it anyway). Here's a file that will break a naive splitter:

name,age,notes
"Smith, John",34,"Likes coffee, hates Mondays"
"Doe, Jane",29,"Says ""hello"" a lot"

A quoted field can contain the delimiter. A quoted field can contain quote characters, escaped by doubling them (""). A quoted field can even contain a literal newline, which means a single CSV "row" might span multiple physical lines in the file. None of this is visible if you just count commas.

Rule one: don't write your own CSV parser. It's a fun weekend project, but every mature CSV library has already solved quoting, escaping, multi-line fields, and the dozen other edge cases you haven't thought of yet. Use one.

A solid baseline: Python

Python's standard library handles the parsing correctly out of the box:

import csv
import json

with open('data.csv', newline='', encoding='utf-8') as f:
    reader = csv.DictReader(f)
    rows = list(reader)

with open('data.json', 'w', encoding='utf-8') as f:
    json.dump(rows, f, indent=2)

That newline='' on the file open isn't decorative — it's required so the csv module can correctly detect line endings inside quoted fields. Skip it and you'll get subtly wrong results on files with embedded newlines.

The output is a JSON array of objects, keyed by the header row:

[
  { "name": "Smith, John", "age": "34", "notes": "Likes coffee, hates Mondays" },
  { "name": "Doe, Jane", "age": "29", "notes": "Says \"hello\" a lot" }
]

Notice age is a string. That's the next problem.

Everything in CSV is a string, and that's a trap

CSV has no type system. 34 is text. true is text. An empty cell is text (or absent, depending on the row). If you want a real JSON number or boolean, you have to convert it yourself — and that's where scripts get sloppy in ways that don't show up until later.

A blind "try to parse everything as a number" approach seems tempting:

def guess_type(value):
    if value == "":
        return None
    if value.lower() in ("true", "false"):
        return value.lower() == "true"
    try:
        return float(value) if "." in value else int(value)
    except ValueError:
        return value

But run it on {"id": "00423", "active": "true"} and id silently becomes 423. If that's a zip code, an account number, or a SKU, you just corrupted your data — leading zeros are the classic CSV-to-JSON landmine. The safer approach is an explicit column-to-type map instead of guessing per value:

SCHEMA = {
    "id": "string",     # keep as-is, don't coerce
    "score": "number",
    "active": "boolean",
}

def coerce(key, value):
    if value == "":
        return None
    kind = SCHEMA.get(key, "string")
    if kind == "boolean":
        return value.lower() in ("true", "yes", "1")
    if kind == "number":
        return float(value) if "." in value else int(value)
    return value

More typing, but it never quietly reinterprets an ID as an integer just because it happens to look like one.

The encoding problem you'll hit eventually

Open a CSV exported from Excel and check the first few bytes — there's a decent chance it starts with a BOM (byte order mark, \ufeff). If you read it as plain UTF-8 without stripping the BOM, it silently attaches itself to your first header name:

# Header looks like "name" but is actually "\ufeffname"
row["name"]  # KeyError, even though the column is right there

The fix is using utf-8-sig instead of utf-8 as the encoding when you open the file:

with open('data.csv', newline='', encoding='utf-8-sig') as f:
    reader = csv.DictReader(f)

Also worth checking: not every CSV is UTF-8 to begin with. Files from older Windows systems or non-English locales sometimes show up as latin-1 or cp1252. If you get garbled characters instead of an outright crash, that's usually the culprit. If you're not sure what you're dealing with, chardet or charset-normalizer can take a decent guess at the encoding before you commit to one.

Delimiters aren't always commas

Plenty of "CSV" files use semicolons instead of commas — common in locales where the comma is the decimal separator (so 3,14 means 3.14, and a comma can't also be the field separator without ambiguity). Excel in those locales exports semicolon-delimited files by default, still with a .csv extension, which trips people up constantly. Tab-separated files also frequently masquerade as .csv.

Both Python's csv module and JS libraries let you set the delimiter explicitly:

reader = csv.DictReader(f, delimiter=';')

If you're building something that accepts arbitrary uploaded CSVs, it's worth sniffing the delimiter rather than assuming:

sample = f.read(2048)
f.seek(0)
dialect = csv.Sniffer().sniff(sample)
reader = csv.DictReader(f, dialect=dialect)

It's not bulletproof, but it catches the semicolon case reliably.

Node.js version, with a real streaming parser

For Node, I'd reach for csv-parse rather than hand-rolling anything:

const fs = require('fs');
const { parse } = require('csv-parse');

const records = [];

fs.createReadStream('data.csv')
  .pipe(parse({ columns: true, skip_empty_lines: true, bom: true }))
  .on('data', (row) => records.push(row))
  .on('end', () => {
    fs.writeFileSync('data.json', JSON.stringify(records, null, 2));
  })
  .on('error', (err) => console.error(err));

The bom: true option handles that BOM issue automatically, and columns: true gives you the same header-keyed objects as Python's DictReader. skip_empty_lines matters more than it sounds — trailing blank lines at the end of exported CSVs are extremely common and will otherwise show up as a row of empty strings in your output.

When the file is too big to hold in memory

Loading everything into an array and calling JSON.stringify works fine until someone hands you a 2GB export. At that point you want to stream rows out as you read them, usually as NDJSON (newline-delimited JSON) rather than one giant JSON array, since NDJSON lets you process the output line by line too:

import csv
import json

with open('huge.csv', newline='', encoding='utf-8-sig') as infile, \
     open('huge.ndjson', 'w', encoding='utf-8') as outfile:
    reader = csv.DictReader(infile)
    for row in reader:
        outfile.write(json.dumps(row) + '\n')

Constant memory usage regardless of file size, because you never hold more than one row at a time. If you genuinely need a single JSON array as output (some downstream consumer requires it), you can still stream the reads and just write the array brackets and commas manually — a bit more bookkeeping, but it avoids loading the whole CSV into memory at once.

Handling malformed rows without crashing the whole job

Real files have bad rows in them — a stray extra comma from a bad export, a row that's missing half its fields. Letting one bad row kill a job processing 500,000 others is usually the wrong tradeoff. Collect the failures instead of raising immediately:

good_rows = []
errors = []

with open('data.csv', newline='', encoding='utf-8-sig') as f:
    reader = csv.DictReader(f)
    expected = set(reader.fieldnames)
    for line_num, row in enumerate(reader, start=2):  # line 1 is the header
        if None in row or None in row.values():
            errors.append({"line": line_num, "reason": "field count mismatch", "raw": row})
            continue
        good_rows.append(row)

print(f"Converted {len(good_rows)} rows, skipped {len(errors)}")

DictReader actually tells you when a row doesn't match the header: extra fields get bundled under the None key, and missing fields come back as None values. Checking for that instead of ignoring it means you find out about bad rows from a log line, not from a confused support ticket three weeks later.

Turning flat columns into nested JSON

CSV is inherently flat — one row, one level of columns. But it's common to want structured output, especially with dot-notation or bracket-notation headers:

name,address.city,address.zip,tags[0],tags[1]
Alex,Portland,97201,dev,remote

into:

{
  "name": "Alex",
  "address": { "city": "Portland", "zip": "97201" },
  "tags": ["dev", "remote"]
}

There's no standard for this — it's a convention some tools support and others don't — but it's straightforward to build:

def unflatten(row):
    result = {}
    for key, value in row.items():
        parts = key.replace(']', '').replace('[', '.').split('.')
        d = result
        for i, part in enumerate(parts):
            is_last = i == len(parts) - 1
            if part.isdigit():
                part = int(part)
            if is_last:
                if isinstance(d, list):
                    while len(d) <= part:
                        d.append(None)
                    d[part] = value
                else:
                    d[part] = value
            else:
                next_is_index = parts[i + 1].isdigit()
                container = [] if next_is_index else {}
                if isinstance(d, list):
                    while len(d) <= part:
                        d.append(None)
                    if d[part] is None:
                        d[part] = container
                    d = d[part]
                else:
                    if part not in d:
                        d[part] = container
                    d = d[part]
    return result

It's more code than you'd think for something that sounds simple — nested-structure reconstruction always is. If you only need this occasionally, it's usually not worth maintaining custom unflattening logic yourself; a lot of teams just add a small transform step after a plain conversion instead of building this into the parser.

Ragged rows and duplicate headers

Beyond the field-count mismatch already mentioned, watch for headers that repeat. If a CSV has two columns both named email (more common than you'd hope, usually from a spreadsheet merge), a plain dict-based approach will silently keep only the last one. Check for it before you trust the output:

with open('data.csv', encoding='utf-8-sig') as f:
    headers = next(csv.reader(f))

duplicates = {h for h in headers if headers.count(h) > 1}
if duplicates:
    print(f"Warning: duplicate columns will overwrite each other: {duplicates}")

Cheap check, saves you from silently dropping data with no error at all.

Bonus: inferring a schema from the CSV itself

If you're handing the resulting JSON off to another team, or writing a TypeScript interface for it, it helps to know the actual shape of the data rather than guessing. A quick pass over all rows per column gives you that (this builds on the reader and good_rows from the malformed-row check earlier):

def infer_column_type(values):
    kinds = set()
    for v in values:
        if v == "":
            kinds.add("null")
        elif v.lower() in ("true", "false"):
            kinds.add("boolean")
        else:
            try:
                int(v)
                kinds.add("integer")
            except ValueError:
                try:
                    float(v)
                    kinds.add("number")
                except ValueError:
                    kinds.add("string")
    non_null = kinds - {"null"}
    if non_null <= {"integer"}:
        return "integer"
    if non_null <= {"integer", "number"}:
        return "number"  # a mix of "10" and "10.5" in one column is still just a number
    if len(non_null) == 1:
        return non_null.pop()
    return "string"  # genuinely mixed types: safest to leave as string

columns = reader.fieldnames
schema = {col: infer_column_type([row[col] for row in good_rows]) for col in columns}
print(schema)
# {'name': 'string', 'age': 'integer', 'active': 'boolean', 'notes': 'string'}

It's rough — real schema inference tools do a lot more validation — but for catching an unexpectedly mixed column (a "phone" field that's mostly numbers but has a few entries like "N/A") before it becomes a type error downstream, this is usually enough.

Quick, one-off conversions without writing code

Not every CSV-to-JSON job needs a script. If it's a one-time thing — a test fixture, a quick check of what an export actually contains — there are lighter options depending on where you're working.

On the command line, csvkit ships a csvjson command that covers the common cases:

pip install csvkit
csvjson data.csv > data.json

Miller (mlr) is another solid option if you're already piping data through Unix tools:

mlr --icsv --ojson cat data.csv > data.json

And if you're on a machine where installing anything isn't an option — someone else's laptop, a locked-down environment — a browser-based converter works too. 99tools' CSV to JSON converter is one of these: paste the CSV in, get JSON back, nothing to install. Like the CLI tools above, you're trading control for convenience — you don't get to decide how empty strings, leading zeros, or non-UTF-8 encoding get handled — so it's better suited to quick fixtures and debugging than anything that runs unattended as part of a pipeline.

A checklist for production conversions

Use a real CSV parser, never manual string splitting
Handle the BOM (utf-8-sig in Python, bom: true in csv-parse)
Decide your delimiter explicitly, or sniff it, don't assume a comma
Convert types deliberately with a column map, not blind inference — leading zeros will bite you
Treat empty strings, null, and "absent key" as three different things and pick one on purpose
Stream large files instead of loading everything into memory
Collect and log malformed rows instead of letting one bad row kill the whole job
Check for duplicate or ragged headers before you trust the output

None of this is complicated once you know it exists — it's just easy to skip when the sample file on your desk happens to be clean. The real CSVs, the ones exported from some legacy system three departments over, are never as clean as the one you tested with.

JSON.stringify() seems simple—until real-world data gets messy. This guide covers the edge cases developers actually hit in production, from undefined and BigInt to circular references, nested JSON, escaping, and stable key order.

99Tools — Fri, 04 Sep 2026 17:24:00 +0000

99Tools

Sep 4

JSON to String Conversion: The Edge Cases That Actually Bite in Production

#javascript #webdev #tutorial #json

9 min read

JSON to String Conversion: The Edge Cases That Actually Bite in Production

99Tools — Fri, 04 Sep 2026 17:18:55 +0000

Every JS developer writes JSON.stringify(data) a hundred times before they ever stop to think about what it's actually doing under the hood. It's one line, it "just works," and most of the time that's a completely fine way to live.

Then one day a field goes missing from a payload for no visible reason. Or a service throws TypeError: Converting circular structure to JSON in the middle of a request handler that was fine yesterday. Or a script tag gets closed early by user-generated content and half your page renders as plain text. None of these are exotic — they're the kind of thing that shows up in a Slack thread titled "why is prod broken" at 6pm on a Friday.

This is a walkthrough of the actual edge cases in converting JSON to strings (and back), why they happen, and how to handle them on purpose instead of discovering them in an incident channel.

The baseline

const user = { id: 1, name: "Ada", active: true };
JSON.stringify(user);
// '{"id":1,"name":"Ada","active":true}'

This works cleanly because every value maps directly onto a JSON type: number, string, boolean. The interesting problems start the moment your data contains anything JSON has no native representation for — which, in a real codebase, is almost immediately.

Problem 1: Values that quietly disappear

JSON has no concept of undefined, functions, or Symbol. JSON.stringify doesn't throw when it meets them — it just drops them, and it does so differently depending on whether they're sitting in an object or an array. This asymmetry trips people up constantly.

const obj = {
  a: 1,
  b: undefined,
  c: () => {},
  d: Symbol("x"),
};
JSON.stringify(obj);
// '{"a":1}'   -- b, c, d are all gone

const arr = [1, undefined, () => {}, Symbol("x")];
JSON.stringify(arr);
// '[1,null,null,null]'  -- same values, but now they become null

I've debugged this exact thing before: code worked fine against an object shape, then someone refactored the same data into an array of records and every "missing" field silently turned into null instead of vanishing. If a field genuinely matters, don't let undefined be the thing that represents its absence — normalize it to null or a real value before you serialize.

Problem 2: Values that silently change

Some types don't disappear — they get converted, and the conversion isn't always the one you'd expect.

JSON.stringify({ n: NaN, i: Infinity, ni: -Infinity });
// '{"n":null,"i":null,"ni":null}'

JSON.stringify({ date: new Date("2026-01-01") });
// '{"date":"2026-01-01T00:00:00.000Z"}'

NaN and Infinity aren't valid JSON, so JSON.stringify folds all three of those distinct values into null — with nothing to tell you which one it originally was. If a downstream consumer needs to distinguish "not a number" from "no value," you need to encode that intent yourself before serializing.

Dates work because Date.prototype.toJSON() exists and internally calls toISOString(). This matters more than it looks: JSON.stringify always checks for a toJSON method on a value before falling back to default handling — and that's the exact mechanism you get to hook into for your own classes (more on that shortly).

Map and Set don't have a toJSON, so they serialize as empty objects, which is a nasty silent failure:

JSON.stringify(new Map([["a", 1]]));
// '{}'

Convert them explicitly before handing them to stringify:

JSON.stringify(Object.fromEntries(myMap));
JSON.stringify([...mySet]);

BigInt doesn't even get the courtesy of a silent conversion — it throws outright:

JSON.stringify({ big: 10n });
// Uncaught TypeError: Do not know how to serialize a BigInt

The usual fix is to stringify it explicitly and give the consumer a hint that it needs to be parsed back as a big integer:

JSON.stringify({ big: 10n.toString() });

Problem 3: Circular references

If an object references itself, directly or through a chain, JSON.stringify throws:

const node = { name: "root" };
node.self = node;

JSON.stringify(node);
// Uncaught TypeError: Converting circular structure to JSON

This shows up more than people expect — DOM nodes, ORM entities with back-references (parent.children[0].parent === parent), event emitters attached to a data object. The fix isn't to redesign your data model around avoiding cycles; sometimes a cycle is the correct shape for your program. The fix is to strip it at serialization time with a replacer that tracks what it's already seen:

function getCircularReplacer() {
  const seen = new WeakSet();
  return (key, value) => {
    if (typeof value === "object" && value !== null) {
      if (seen.has(value)) return "[Circular]";
      seen.add(value);
    }
    return value;
  };
}

JSON.stringify(node, getCircularReplacer());
// '{"name":"root","self":"[Circular]"}'

Controlling serialization on purpose

Rather than reacting to these one at a time, it's usually better to decide up front exactly how a value should serialize.

`toJSON()`

Any object can define a toJSON() method, and JSON.stringify will use its return value instead of the object itself — everywhere, automatically, without every call site needing to know about it:

class Money {
  constructor(cents, currency) {
    this.cents = cents;
    this.currency = currency;
  }
  toJSON() {
    return `${(this.cents / 100).toFixed(2)} ${this.currency}`;
  }
}

JSON.stringify({ price: new Money(1999, "USD") });
// '{"price":"19.99 USD"}'

This is the cleanest way to make a custom class work correctly with JSON.stringify no matter where in the codebase it gets serialized.

The replacer function

For one-off control — redacting fields, transforming values in a specific context — pass a replacer function as the second argument. It's called for every key/value pair, starting with a synthetic top-level wrapper:

const payload = { username: "ada", password: "hunter2", email: "ada@example.com" };

JSON.stringify(payload, (key, value) => {
  if (key === "password") return undefined; // drop it
  return value;
});
// '{"username":"ada","email":"ada@example.com"}'

You can also pass a plain array of allowed keys instead of a function, if all you need is a simple allow-list:

JSON.stringify(payload, ["username", "email"]);
// '{"username":"ada","email":"ada@example.com"}'

The reviver function (parsing back)

The inverse problem shows up on JSON.parse: dates come back as plain strings, not Date objects, because JSON has no date type. A reviver lets you reconstruct richer types as parsing happens, rather than post-processing the whole tree afterward:

const json = '{"name":"Ada","createdAt":"2026-01-01T00:00:00.000Z"}';

const obj = JSON.parse(json, (key, value) => {
  if (key === "createdAt") return new Date(value);
  return value;
});

obj.createdAt instanceof Date; // true

The reviver runs bottom-up on every node in the tree, so nested dates several levels deep get converted too — which is exactly why it's worth using instead of a manual walk after parsing.

Formatting: compact vs. readable

The third argument to JSON.stringify controls indentation:

JSON.stringify({ a: 1, b: { c: 2 } }, null, 2);

{
  "a": 1,
  "b": {
    "c": 2
  }
}

Use compact output (no third argument) for anything going over the network or into storage — indentation is pure overhead there. Use 2 or "\t" for logs, config files, and debug output that a human is actually going to read. It's an easy thing to leave on by accident in an API response and quietly bloat every payload by 20-30% for no reason at all.

Embedding a JSON string inside something else

This is where a lot of the subtle bugs actually live, because at this point you're not doing "JSON to string" once — you're doing it inside another format, and that outer format's own escaping rules now apply too.

Inside an HTML `<script>` tag

A classic mistake when server-rendering initial state into a page:

// DON'T do this directly:
`<script>window.__DATA__ = ${JSON.stringify(data)}</script>`

If data contains the literal substring </script>, the browser's HTML parser closes your script tag early — before the JS parser ever gets a chance to look at the content — and the rest gets rendered as raw visible text. This is both a rendering bug and a potential XSS vector the moment any part of data comes from user input.

The fix is to escape <, >, and & inside the JSON string before embedding it:

function escapeForScriptTag(json) {
  return json.replace(/</g, "\\u003c").replace(/>/g, "\\u003e").replace(/&/g, "\\u0026");
}

const safe = escapeForScriptTag(JSON.stringify(data));
`<script>window.__DATA__ = ${safe}</script>`

\u003c is a valid escape sequence in both JSON and JS, so this doesn't change the parsed value at all — it just stops the HTML parser from misreading it before your JS ever runs.

JSON inside JSON

Sometimes a payload needs to carry an entire JSON document as a string field — this is a common pattern in message queues and audit logs. You stringify it twice:

const inner = { type: "click", x: 10, y: 20 };
const envelope = {
  eventId: "evt_123",
  payload: JSON.stringify(inner), // stringified once, embedded as a string
};

JSON.stringify(envelope);
// '{"eventId":"evt_123","payload":"{\\"type\\":\\"click\\",\\"x\\":10,\\"y\\":20}"}'

Notice the escaped quotes (\\") — that's JSON.stringify correctly escaping the inner JSON string so it remains a valid string value inside the outer document. Trying to hand-build this with string concatenation is exactly how you end up with malformed JSON that only fails once real data hits it.

If you're doing this kind of escaping as a one-off — pasting a payload into a .env file, a Kubernetes secret, or a raw SQL INSERT while debugging something manually — it's not always worth writing a script for a single conversion. A browser-based JSON to string converter that just escapes quotes, backslashes, and newlines and hands you the quoted output can save the two minutes it'd take to spin up a snippet, since it runs client-side and doesn't require you to trust it with anything sensitive server-side. It's the same transformation as the code above, just without writing the code when you only need it once.

Key order isn't guaranteed the way you might assume

JSON.stringify preserves insertion order for string keys, with one twist: integer-like keys are always sorted numerically first, ahead of everything else, regardless of insertion order.

JSON.stringify({ b: 1, a: 2, 2: "x", 1: "y" });
// '{"1":"y","2":"x","b":1,"a":2}'

This matters if you're using a stringified object as a cache key, a hash input, or for diffing two objects — two objects with identical data but different key insertion order will not produce the same string, and any hash comparison between them will fail. If you need a stable, comparable string, sort the keys yourself before serializing:

function stableStringify(obj) {
  if (obj === null || typeof obj !== "object") return JSON.stringify(obj);
  if (Array.isArray(obj)) return `[${obj.map(stableStringify).join(",")}]`;
  const keys = Object.keys(obj).sort();
  const pairs = keys.map(k => `${JSON.stringify(k)}:${stableStringify(obj[k])}`);
  return `{${pairs.join(",")}}`;
}

For anything beyond a quick script, reach for a well-tested library like fast-json-stable-stringify rather than maintaining this by hand — edge cases around NaN, undefined, and nested dates pile up faster than you'd expect.

Cross-language interop: the differences bite in production

If your JSON is produced by one language and consumed by another, some of this is not consistent across ecosystems — and it's rarely caught until two services that "both just use JSON" start talking to each other.

Python's json.dumps allows NaN and Infinity by default and emits the literals NaN, Infinity, -Infinity — none of which are valid JSON per spec. A JS JSON.parse on the receiving end throws a SyntaxError on that payload. Pass allow_nan=False if the consumer isn't Python, or sanitize those values before serializing.
Java (Jackson) and JS both fall back to some default behavior for types the format doesn't natively support, but the specifics — how enums, dates, and "null vs. absent field" are handled — differ enough that it's worth writing an actual contract test between services rather than assuming symmetry.
Key order is not part of the JSON spec at all. Don't design a system that depends on it surviving a network boundary, even if it happens to hold up in your current stack.

A quick checklist

Before shipping a JSON.stringify call, it's worth running through:

Does the data contain undefined, functions, Symbols, Map/Set, or BigInt that need explicit handling?
Could the object graph be circular?
Does this need a stable key order for hashing or diffing?
Is the result going into HTML, another JSON string, a URL, or a shell command — and does it need escaping for that context, not just JSON's own rules?
Is pretty-printing actually needed here, or is it wasted bytes on the wire?

None of these are exotic. They're the ones that surface in code review, in production incidents, and in "why does this only break in prod" debugging sessions. Handling them on purpose — with toJSON(), a replacer, or a small utility function — is a lot cheaper than finding out about them from a stack trace.

Think JSON.stringify() is simple? Think again. Learn how JSON to String conversion really works, avoid common mistakes, handle edge cases, and write cleaner JavaScript with practical examples you can use today.

99Tools — Thu, 30 Jul 2026 14:36:55 +0000

99Tools

Jul 30

JSON to String in JavaScript: The Complete Guide (And the Gotchas That Bite Even Experienced Devs)

#javascript #webdev #tutorial #beginners

10 min read

JSON to String in JavaScript: The Complete Guide (And the Gotchas That Bite Even Experienced Devs)

99Tools — Thu, 30 Jul 2026 14:33:57 +0000

A few years back, I spent about twenty minutes debugging why a user's shopping cart kept resetting on page refresh. The code looked completely fine:

localStorage.setItem("cart", cartItems);

Open dev tools, check localStorage, and there it is: "[object Object]". Not the data. Just that string, staring back at me.

That bug — and the dozens of variations of it I've seen since, in code reviews and Stack Overflow threads alike — comes down to one missing step: turning a JavaScript object into an actual JSON string before handing it to something that only understands strings. This guide covers that step in depth: how it works, where you'll use it, and the edge cases that will eventually get you if nobody tells you about them first.

TL;DR

Use JSON.stringify(value) to convert a JS value into a JSON-formatted string.
Use JSON.stringify(value, null, 2) when you want it human-readable.
undefined, functions, and symbols are silently dropped. NaN and Infinity become null.
Circular references and BigInt values throw errors — they don't fail quietly.
JSON.parse(JSON.stringify(x)) is not a safe deep clone. Use structuredClone(x) instead.
JSON.parse(str, reviver) lets you rebuild things like Date objects on the way back in.

If you already know all that, you probably don't need this article — but stick around anyway, there are a couple of gotchas below that surprise even people who've been writing JavaScript for years.

First, Let's Clear Up the Terminology

"JSON" stands for JavaScript Object Notation, and it's a text format — it's already string-shaped by definition. So when developers say "convert JSON to a string," what they almost always mean is:

"I have a JavaScript object (or array, or value), and I need to represent it as JSON-formatted text."

That distinction matters, because it's not the same operation as "converting an object to a string" in the generic sense. Which brings us to a trap a lot of beginners fall into first.

The Wrong Way (and Why It Fails)

If you're new to JavaScript, converting a value "to a string" might reasonably make you reach for String(), .toString(), or a template literal. Try that on an object, though, and here's what happens:

const user = { name: "Maya", age: 29 };

String(user);        // "[object Object]"
`${user}`;            // "[object Object]"
user.toString();      // "[object Object]"

All three quietly return the same useless placeholder. That's because objects don't have meaningful default string representations — [object Object] is just JavaScript telling you "yep, this is an object," which you already knew.

JSON.stringify() is a different operation entirely. Instead of asking "what's the string form of this object," it serializes the object — walking through its structure and producing a text representation of the data itself:

JSON.stringify(user);
// '{"name":"Maya","age":29}'

That's the method you actually want.

The Core Method: `JSON.stringify()`

const user = {
  name: "Maya",
  age: 29,
  isActive: true
};

const jsonString = JSON.stringify(user);

console.log(jsonString);
// '{"name":"Maya","age":29,"isActive":true}'

console.log(typeof jsonString);
// "string"

Your object is now plain text. It looks like the object literal you started with, but functionally it isn't — you can't do jsonString.name anymore, because there's no object there to access. If you need the data back in object form, you'll need JSON.parse(), which we'll get to.

Making Output Readable: The Indentation Argument

Compact JSON is great for sending over a network, but it's rough to read in a console log or a debug file. JSON.stringify() accepts a third argument for that:

JSON.stringify(user, null, 2);
/*
{
  "name": "Maya",
  "age": 29,
  "isActive": true
}
*/

The 2 means "indent with 2 spaces." You could pass 4, or even a string like "\t" for tabs. I default to 2 in almost every debugging session I run — it turns a wall of text into something I can actually scan.

Controlling What Gets Included: The Replacer

The second argument — the one we skipped with null above — is called the replacer, and it's more powerful than most quick tutorials let on.

As a function, it runs against every key/value pair, so you can filter or transform data on the way out:

const account = {
  username: "maya_codes",
  password: "supersecret123",
  email: "maya@example.com"
};

const safeJson = JSON.stringify(account, (key, value) => {
  if (key === "password") return undefined;
  return value;
});

console.log(safeJson);
// '{"username":"maya_codes","email":"maya@example.com"}'

This is genuinely useful for scrubbing sensitive fields — tokens, passwords, internal IDs — before you log an object or send it somewhere it shouldn't end up.

As an array, it works as a simple whitelist instead:

JSON.stringify(account, ["username", "email"]);
// '{"username":"maya_codes","email":"maya@example.com"}'

Same result, less code — but no custom logic, so pick whichever fits your situation.

Custom Serialization With `toJSON()`

Here's a trick that doesn't get nearly enough attention: any object can define its own toJSON() method, and JSON.stringify() will call it automatically instead of serializing the object's raw properties.

class Money {
  constructor(cents) {
    this.cents = cents;
  }

  toJSON() {
    return (this.cents / 100).toFixed(2);
  }
}

const price = new Money(1999);

console.log(JSON.stringify({ price }));
// '{"price":"19.99"}'

This is exactly how Date objects manage to serialize cleanly (more on that below) — Date.prototype.toJSON() is built in. If you're building your own classes and want them to serialize predictably, this is the hook to use instead of fighting with replacer functions everywhere they're used.

Where You'll Actually Use This

Storing Data in `localStorage` or `sessionStorage`

Both storage APIs only accept strings — this is the bug from the intro:

const cartItems = [{ id: 1, qty: 2 }, { id: 2, qty: 1 }];

localStorage.setItem("cart", JSON.stringify(cartItems));

// later:
const cart = JSON.parse(localStorage.getItem("cart"));

Sending Data With `fetch()`

Request bodies are strings too, not live objects:

fetch("/api/orders", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ item: "Keyboard", quantity: 1 })
});

Skip this step, and your server usually receives something it can't parse, no matter what the Content-Type header claims.

Logging and Debugging

Deeply nested objects often get truncated or collapsed in browser and Node consoles. Stringifying first gives you a flat snapshot you can actually read or paste into a bug report:

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

Comparing or Hashing Objects

JSON.stringify() is also a common (if imperfect) shortcut for comparing two objects by value, since JavaScript's === only checks reference equality:

const a = { x: 1, y: 2 };
const b = { x: 1, y: 2 };

a === b; // false
JSON.stringify(a) === JSON.stringify(b); // true

It's worth knowing this trick exists — just also worth knowing it breaks if the keys are in a different order or the objects contain any of the quirks below. For anything beyond quick scripts or tests, a proper deep-equality check (like lodash.isEqual) is more reliable.

The Gotchas (Learned the Hard Way)

Some Values Just Disappear

JSON.stringify() silently drops undefined values, functions, and Symbol keys — no error, no warning:

const obj = {
  name: "test",
  greet: function () { return "hi"; },
  id: undefined,
  tag: Symbol("x")
};

console.log(JSON.stringify(obj));
// '{"name":"test"}'

If a field you swear you set is missing from an API payload or a stored object, this is worth checking first.

`NaN` and `Infinity` Become `null`

JSON.stringify({ score: NaN, limit: Infinity });
// '{"score":null,"limit":null}'

JSON has no concept of these values, so JSON.stringify() falls back to null instead of throwing.

Circular References Throw

If an object references itself — directly or through a chain — JSON.stringify() doesn't skip it quietly. It throws:

const node = { name: "root" };
node.self = node;

JSON.stringify(node);
// TypeError: Converting circular structure to JSON

This tends to catch people off guard with things like DOM nodes, certain framework internals, or ORM models that reference their own parent. If you genuinely need to serialize a structure like that, you'll need a custom replacer that tracks visited references, or a library built specifically for that case.

`BigInt` Isn't Supported — At All

JSON.stringify({ total: 10n });
// TypeError: Do not know how to serialize a BigInt

There's no built-in workaround here. If you're working with BigInt, convert it to a Number or String before stringifying.

`Date` Serializes Cleanly, But Doesn't Come Back the Same Way

Thanks to toJSON(), dates convert into ISO strings automatically:

JSON.stringify({ createdAt: new Date() });
// '{"createdAt":"2026-07-30T09:15:00.000Z"}'

The catch: JSON.parse() has no idea that string used to be a Date. You get a plain string back, and if you need real Date behavior again, you have to reconstruct it yourself — which is exactly what the reviver function below is for.

`Map`, `Set`, and Class Instances Don't Serialize the Way You'd Expect

JSON.stringify(new Map([["a", 1]])); // '{}'
JSON.stringify(new Set([1, 2, 3]));  // '{}'

Both come back as empty objects, because JSON.stringify() only looks at enumerable own properties, and neither Map nor Set store their data that way. If you need to serialize either, convert them first:

JSON.stringify(Array.from(myMap.entries()));
JSON.stringify(Array.from(mySet));

Key Order Isn't Always What You Typed

For most objects, JSON.stringify() preserves the order you added keys in. But if any of your keys look like array indexes ("0", "1", "2"), JavaScript sorts those numerically before everything else, regardless of insertion order. It's a small quirk, but it's caused real confusion in code that assumed key order was purely insertion-based.

The Security Gotcha Nobody Mentions

If you're doing server-side rendering and embedding data directly into an HTML <script> tag — a common pattern for hydrating client-side state — there's a real risk hiding in plain sight:

app.get("/", (req, res) => {
  const data = { bio: userInput }; // e.g. "</script><script>alert(1)</script>"

  res.send(`
    <script>
      window.__DATA__ = ${JSON.stringify(data)};
    </script>
  `);
});

If userInput contains </script>, the browser closes your script tag early — and anything after it gets parsed as raw HTML, including a second <script> tag an attacker controls. JSON.stringify() does not escape this for you by default.

The fix is to escape the characters that matter before embedding:

function safeStringify(data) {
  return JSON.stringify(data)
    .replace(/</g, "\\u003c")
    .replace(/>/g, "\\u003e")
    .replace(/\u2028/g, "\\u2028")
    .replace(/\u2029/g, "\\u2029");
}

(The last two handle the Unicode line/paragraph separators, which are valid in JSON strings but invalid inside a JavaScript string literal — another one that's caused real production bugs.) If you're already using something like serialize-javascript on the server, it handles this for you — but it's worth knowing why that step exists rather than treating it as boilerplate.

The "Quick Deep Clone" Trick Has Real Limits

You'll see this pattern used constantly for cloning objects:

const copy = JSON.parse(JSON.stringify(original));

It works fine for flat, plain data — but given everything above, it quietly breaks on dates, undefined values, functions, Map/Set instances, and circular references. In modern JavaScript, there's a better option:

const copy = structuredClone(original);

structuredClone() is built into modern browsers and Node.js 17+, and it correctly handles dates, Map, Set, and circular references — no serialization round-trip required.

Going the Other Direction: `JSON.parse()`

You'll use JSON.parse() just as often as JSON.stringify(), so it's worth covering properly rather than as an afterthought.

The Basics

const raw = '{"name":"Maya","age":29}';
const parsed = JSON.parse(raw);

console.log(parsed.name); // "Maya"

Always Wrap It in `try/catch`

Any time the string comes from outside your code — an API, a file, user input — treat it as untrustworthy. Malformed JSON throws a SyntaxError, and an uncaught one will crash whatever function it's sitting in:

try {
  const data = JSON.parse(userSuppliedString);
} catch (err) {
  console.error("That wasn't valid JSON:", err.message);
}

Rebuilding Types With a Reviver Function

Remember how dates turn into plain strings when they come back through JSON.parse()? A reviver function fixes exactly that:

const raw = '{"createdAt":"2026-07-30T09:15:00.000Z","count":5}';

const parsed = JSON.parse(raw, (key, value) => {
  if (key === "createdAt") return new Date(value);
  return value;
});

console.log(parsed.createdAt instanceof Date); // true

It runs on every key/value pair, bottom-up, letting you rebuild Date objects, class instances, or anything else that got flattened into plain data during serialization.

When You Just Need a Quick, One-Off Conversion

Not every situation calls for opening an editor. Sometimes you've copied JSON from an API response, a bug report, or a teammate's Slack message and simply need to convert it into an escaped string or verify that the output looks correct before using it in code.

While you can always use JSON.stringify() in JavaScript, a browser-based tool can be quicker when you don't want to write a temporary script. For example, this JSON to String Converter lets you paste JSON and instantly see the escaped string output, which is handy for debugging, creating test data, or preparing JSON for configuration files.

`JSON.stringify()` vs. the Alternatives

Method	Output	Handles nested objects?	Notes
`String(obj)` / `${obj}`	`"[object Object]"`	No	Never use this for data — it's not serialization
`obj.toString()`	`"[object Object]"` (unless overridden)	No	Same issue, unless the class defines its own `toString()`
`JSON.stringify(obj)`	Full JSON text	Yes	The correct tool for this job
`util.inspect(obj)` (Node.js)	Formatted, colorized text	Yes	Great for terminal debugging, but not valid JSON — don't send this anywhere

Quick Reference: Best Practices

Always JSON.stringify() before storing or transmitting — localStorage, fetch bodies, and WebSocket messages all expect strings, not live objects.
Always wrap JSON.parse() in try/catch when the source isn't fully trusted.
Use the indentation argument (JSON.stringify(data, null, 2)) for readable logs and debug output.
Use a replacer function to strip sensitive fields before logging or transmitting data.
Give custom classes a toJSON() method if you want predictable, reusable serialization instead of scattering replacer logic everywhere.
Don't rely on JSON.parse(JSON.stringify(x)) for deep cloning — reach for structuredClone() instead.
Escape user-controlled data before embedding JSON in a <script> tag — JSON.stringify() alone isn't safe for that context.
Remember what silently disappears: undefined, functions, and symbols vanish without warning; NaN and Infinity become null; Map and Set serialize as {} unless converted first.

Wrapping Up

JSON.stringify() and JSON.parse() look like two-line utility functions, and most of the time, that's exactly how simple they are to use. The edge cases in this article are the ones that don't show up until you hit them in production — a Date that silently loses its type, a circular reference that crashes a request handler, a password that leaked into a log file because nobody added a replacer.

None of these are hard to avoid once you know they exist. That's really the whole point of writing them down: so the next twenty minutes you'd have spent debugging one of them, you spend building something instead.

If you want to see these behaviors for yourself, the fastest way is to open your browser console right now and run a few of the examples above — especially the circular reference one. Watching it throw is a lot more memorable than reading about it.

Why Your Regex Works in Testing But Breaks in Production

99Tools — Fri, 24 Jul 2026 17:58:02 +0000

You write a regex. You test it against two or three sample strings. It matches perfectly. You ship it.

Three days later, someone opens a bug report titled "validation is broken" and attaches a screenshot that makes no sense to you, because the exact same pattern worked fine when you tried it.

If this has happened to you, you're not bad at regex. You just tested it the way most of us do — against clean, predictable, hand-picked strings. Production doesn't send you clean, predictable, hand-picked strings. It sends you whatever your users, your APIs, and your database actually contain.

Let's go through the specific reasons a regex that passes your tests can still fail in the real world, with examples for each one.

1. Greedy quantifiers eat more than you think

Say you want to strip HTML tags out of a string. You write this:

const stripped = "<div>hello</div>".replace(/<.*>/g, "");
console.log(stripped); // "hello" — looks correct!

You test it, it works, you move on. Then someone passes in real markup with more than one tag on the same line:

const stripped = "<div><span>hello</span></div>".replace(/<.*>/g, "");
console.log(stripped); // "" — everything is gone

.* is greedy by default. It doesn't stop at the first > it finds — it grabs as much as possible and only backs off if the rest of the pattern fails to match. So instead of matching <div> and </div> separately, it matches from the very first < to the very last > in the string, swallowing your actual content along with it.

The fix is usually a lazy quantifier:

"<div><span>hello</span></div>".replace(/<.*?>/g, "");
// "hello" — correct

The bug here isn't that greedy matching is "wrong." It's that your test string only had one tag, so greedy and lazy behaved identically. Real HTML rarely does.

2. Anchors don't mean what you assume across multiline input

^ and $ match the start and end of the string, not the start and end of every line — unless you explicitly tell the engine otherwise.

const log = `INFO: server started
ERROR: connection refused
INFO: retrying`;

const errorLines = log.match(/^ERROR:.*$/g);
console.log(errorLines); // null

This will pass a quick manual test if you only test it against a single-line string like "ERROR: connection refused". It quietly breaks the moment your real input is a multiline log file, config file, or textarea value — which is most of the time in production.

The fix is the m flag:

const errorLines = log.match(/^ERROR:.*$/gm);
console.log(errorLines); // ["ERROR: connection refused"]

If you also need . to match across line breaks (for example, matching a block that spans multiple lines), you need the s flag as well. These two flags get confused for each other constantly, and mixing them up is one of the most common causes of "it matched locally but not on the server."

3. The `/g` flag is stateful, and that will bite you

This one surprises a lot of people who've been writing JavaScript for years.

When you use the g flag with .test() or .exec(), the regex object remembers where it left off via a lastIndex property. If you reuse that same regex object across multiple calls, the results depend on how many times you've already called it.

const re = /foo/g;

console.log(re.test("foo bar")); // true
console.log(re.test("foo bar")); // false! lastIndex is now past the match
console.log(re.test("foo bar")); // true again

Now imagine that regex is defined once at the top of a module and reused to validate items in a loop:

const re = /^\d+$/g;
const ids = ["123", "456", "789"];

ids.forEach(id => {
  console.log(id, re.test(id));
});
// 123 true
// 456 false   <-- wrong, 456 is a perfectly valid match
// 789 true

In testing, you probably ran this once, saw true, and called it done. In production, it runs against a whole array or a whole stream of requests, and every other item mysteriously fails. This exact bug has shipped in real validation logic more than once, because a single test() call in isolation looks completely correct.

The fix: don't reuse a global regex object for independent checks, or reset lastIndex = 0 before each use, or just skip the g flag when you're only checking a single string.

4. Your test data was ASCII. Your users are not.

If your test strings are all plain English letters and numbers, you will never catch encoding and Unicode issues before they reach production.

const nameRegex = /^[a-zA-Z]+$/;

console.log(nameRegex.test("James"));   // true
console.log(nameRegex.test("José"));    // false
console.log(nameRegex.test("张伟"));     // false

If your app has any international users at all, a name field validated this way will reject real, legitimate names. This isn't a rare edge case in production — it's a routine Tuesday for any product with a global user base.

Similarly, character counting gets weird with emoji and other multi-codepoint characters:

const str = "👨‍👩‍👧‍👦";
console.log(str.length); // 11, not 1

That single family emoji is actually made of multiple Unicode code points joined together, and a regex that assumes "one character = one match" will slice right through the middle of it. The u flag helps the engine treat Unicode properly, but it doesn't fix everything on its own — this is genuinely one of the trickier areas of regex, and it's worth testing deliberately rather than assuming.

5. Catastrophic backtracking: fine in dev, a production incident under load

This is the scariest one, because it doesn't show up as "wrong output." It shows up as your server hanging or your CPU spiking.

const evilRegex = /^(a+)+$/;
const badInput = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!";

// This can take an extremely long time to fail
console.log(evilRegex.test(badInput));

Nested quantifiers like (a+)+ can create an explosion of possible ways to backtrack when the string almost-but-not-quite matches. With short test strings, this finishes instantly and you'd never notice a problem. Feed it a longer string that fails near the end, and the number of backtracking paths grows exponentially. This is called ReDoS (Regular Expression Denial of Service), and it's a real, documented cause of production outages — not a theoretical CS-class example.

The practical takeaway: avoid nested repetition where an inner group and an outer group can both match the same characters, and be especially careful with any regex that runs on user-supplied input.

Testing Regex Against Real Conditions, Not Clean Strings

None of these bugs are exotic. They all come from the same root cause: testing a pattern against input that is cleaner and simpler than what production actually sends.

A few practical ways to prevent this:

Test against messy, realistic data. Multiline strings, mixed casing, non-English characters, unusually long inputs, and empty strings should all be part of your test set — not just the happy path.
Test each flag combination deliberately. Avoid adding g or m flags simply because a Stack Overflow thread suggested it — understand exactly how each flag alters your match behavior.
Watch the match happen, not just the final result. Catching a greedy quantifier grabbing too much or an anchor matching the wrong boundary is much easier when you can visualize captured characters instead of just checking a true/false console output. Pasting a pattern into an interactive Regex Tester before submitting a pull request helps you observe highlighted matches update in real time as edge-case inputs are added. This makes greedy-vs-lazy and boundary errors immediately obvious.
Check across engines if your code touches multiple languages. JavaScript, Python, and PCRE (used by PHP and tools like grep) do not share identical syntax support. Lookbehind capability, named group syntax, and flag behavior frequently differ. A regex ported from Python to JavaScript (or vice versa) rarely works identically without adjustments.
Treat user-input regex as a performance risk. Beyond correctness, patterns with nested quantifiers can suffer from severe catastrophic backtracking when processing adversarial input. Always evaluate execution efficiency on edge-case strings.

The short version

Regex bugs in production almost never come from writing the "wrong" pattern. They come from a pattern that's correct for the input you tested and wrong for the input you didn't think to test. Multiline text, non-English characters, repeated calls with a stateful g flag, and unusually long or malformed strings are exactly the kind of input your manual tests tend to skip — and exactly the kind of input production sends you constantly.

Next time you write a pattern, try to break it on purpose before someone else breaks it by accident.

Stop Sending Bloated JSON: A Simple Optimization Every Developer Should Know

99Tools — Wed, 22 Jul 2026 14:07:55 +0000

Open your browser's network tab on almost any API you've built and look at a response payload. Chances are it's pretty-printed — two-space indentation, line breaks after every key, the works. That's great in Postman. It's dead weight on the wire.

This isn't a "you're doing everything wrong" post. Pretty-printed JSON is easier to read, and readability matters during development. The problem is when that same formatting ships to production unchanged, on every request, forever. It's one of those optimizations that takes five minutes and nobody ever gets around to.

What "bloated" actually means here

JSON has no concept of formatting. {"id":1} and the same object spread across five indented lines are semantically identical — the parser doesn't care. Every space, newline, and indentation level in a pretty-printed payload exists purely for human eyes and costs you bytes for no functional reason.

Here's a single object from an API response, formatted the way most frameworks output it by default:

{
  "id": 1,
  "uuid": "9c3f0001-a1b2-4e5f-8c9d-000000000001",
  "name": "Dev Smith",
  "email": "dev.smith@example.com",
  "is_active": false,
  "created_at": "2026-02-08T10:15:00Z",
  "roles": [
    "admin"
  ],
  "address": {
    "street": "693 Main St",
    "city": "Lagos",
    "zip": "21395"
  }
}

That's 303 bytes. Strip the formatting and you get:

{"id":1,"uuid":"9c3f0001-a1b2-4e5f-8c9d-000000000001","name":"Dev Smith","email":"dev.smith@example.com","is_active":false,"created_at":"2026-02-08T10:15:00Z","roles":["admin"],"address":{"street":"693 Main St","city":"Lagos","zip":"21395"}}

241 bytes. Same data, same structure, 20% smaller. For one object that's nothing. Multiply it across a paginated response with 50 objects and it stops being nothing.

Measuring it on a real payload

I generated a realistic API response — a paginated user list, 50 records, each with an id, uuid, email, a roles array, and a nested address object — and measured it three ways: pretty-printed, minified, and both of those gzipped. Here's the actual output:

Pretty-printed JSON size:       19193 bytes
Minified JSON size:             12594 bytes
Bytes saved by minifying alone: 6599 (34.4% smaller)

Pretty-printed JSON, gzipped:   2050 bytes
Minified JSON, gzipped:         1929 bytes
Bytes saved after gzip too:     121 (5.9% smaller)

Read those two blocks together, because the second one is the part most "minify your JSON!" posts skip, and it matters more than the first.

The gzip question

If your API sits behind a server that gzips responses (which, on HTTPS in 2026, is most of them), a huge chunk of that whitespace savings evaporates. Gzip is extremely good at compressing repetitive characters, and indentation is about as repetitive as text gets. In the numbers above, minifying saved 34.4% uncompressed but only 5.9% once gzip was applied to both versions. The compressed minified file was still smaller — just not dramatically.

So the honest answer to "should I minify my JSON?" is: it depends on where compression happens, and whether it happens at all.

Minification still earns its keep in a few specific situations:

Uncompressed responses. Not every endpoint goes through gzip/brotli — internal services, some CDNs with caching quirks, and plenty of misconfigured servers serve JSON uncompressed. Here the 34% isn't theoretical, it's what actually goes over the wire.
WebSocket and real-time messages. permessage-deflate compression exists for WebSockets but isn't always enabled, and a lot of high-frequency message protocols (game state updates, live dashboards, trading data) skip compression entirely because the CPU overhead per tiny message isn't worth it. Minifying costs nothing at send time and shrinks every single frame.
Mobile and constrained networks. Even compressed, smaller is still smaller, and on a flaky connection every byte affects time-to-first-render.
Storage and logging pipelines. If you're storing millions of JSON blobs — event logs, audit trails, cached API responses — the indentation overhead adds up in disk and in what you pay for it, independent of anything that happens over the network.
Before compression runs at all. If you minify before gzip instead of after, you're not fighting compression, you're just feeding it less redundant input. It still helps, it just helps less than the raw number suggests.

Where it barely matters: a typical REST API response served over HTTPS with gzip/brotli already on, where response sizes are in the low kilobytes. You're optimizing 6% of an already-small number. Worth doing if it's free (a one-line config change), not worth an engineering sprint.

How to actually do it

This is the easy part, which is exactly why it's worth doing — the cost is close to zero.

JavaScript / Node — JSON.stringify minifies by default. The formatting you see in dev tools comes from the third argument:

// Pretty (for humans, debugging, config files)
JSON.stringify(data, null, 2);

// Minified (for the wire)
JSON.stringify(data);

If your API framework is pretty-printing responses, it's almost always because someone explicitly configured an indent for development and it never got turned off for production. Check your res.json() / serializer config.

Python:

import json

# Default is already fairly compact, but separators removes the extra space
# after commas and colons that json.dumps adds by default
minified = json.dumps(data, separators=(",", ":"))

Command line, with jq:

jq -c . input.json > output.json

-c is compact output — same data, no formatting.

Quick one-off check. If you just want to quickly strip formatting and test a payload without wiring anything into your build — say, you're debugging an API response on the fly and want to strip whitespace immediately — you can paste it into a browser-based tool like the JSON minifier to collapse it instantly, no setup required. Useful for a quick sanity check before you decide whether it's worth automating in your codebase.

For anything that runs repeatedly — API responses, build artifacts, CI output — automate it at the framework or build-tool level rather than doing it by hand. A one-time manual minify on a static file is fine; a manual step in a deploy pipeline is a bug waiting to happen.

Going further: the array-of-objects problem

Whitespace isn't the only source of bloat. If you have a large array of objects that all share the same keys, you're repeating those key names on every single element — and that repetition survives minification, because the keys are still there.

Same 50-record user list, keys only (id, uuid, name, email, is_active, created_at), compared as an array of objects versus a columnar structure (one array per field, aligned by index):

Row-based (array of objects), minified: 8142 bytes
Columnar (object of arrays), minified:  5506 bytes
Saved: 2636 bytes (32.4% smaller)

That's the classic row-based vs. columnar tradeoff:

// Row-based — key names repeated 50 times
[
  {"id":1,"name":"Dev Smith","is_active":false},
  {"id":2,"name":"Alice Johnson","is_active":true}
]

// Columnar — key names appear once
{
  "id": [1, 2],
  "name": ["Dev Smith", "Alice Johnson"],
  "is_active": [false, true]
}

Interestingly, even gzip didn't fully erase this difference — the compressed columnar version was still about 7.7% smaller than the compressed row-based one in this test, because gzip's window doesn't always catch every repeated key across a large array as efficiently as removing the repetition outright.

This is a real technique used in analytics and data-transfer formats (it's the whole idea behind Arrow and Parquet), but it's a bigger structural change than flipping a minify flag — it breaks the natural "one object per record" shape that most client code expects, so it's worth reaching for only when you're moving genuinely large arrays, not as a default for every endpoint.

Where minification bites you

A few things to watch for before you apply this everywhere:

Don't minify anything a human needs to read or diff. Config files, fixtures, seed data, anything committed to git — keep those pretty-printed. A minified config file that breaks in production is miserable to debug, and a minified JSON file in a pull request makes every diff useless.
It doesn't fix ambiguous data. Duplicate keys in an object, inconsistent types across an array, deeply nested structures that should've been flattened — minifying changes byte count, not data quality. If your JSON has structural problems, minifying just makes them smaller and harder to spot.
Comments aren't valid JSON either way. If you're relying on // comments in a .json file for documentation, that's actually JSON5 or JSONC, not JSON — a different problem than formatting, but worth knowing minification tools won't preserve those comments if you run them against a strict JSON parser.
Logs are for reading later. If you're minifying application logs to save disk space, fine — but make sure whatever reads them back (log viewer, jq, alerting rules) can still parse compact JSON. Most can; some older tooling assumes one key-value pair per line.

The actual checklist

Production API responses: minify. It's a one-line config change in most frameworks, so there's little reason not to, even where gzip is already doing most of the work.
Real-time / WebSocket / streaming messages: minify, especially if compression isn't enabled on that channel.
Config files, fixtures, anything committed to source control: keep pretty-printed.
Large arrays of uniform objects moving significant data: consider a columnar structure, but only when the size actually justifies the added complexity on the receiving end.
Before optimizing further: check whether gzip/brotli is even on. If it's off, turning it on will usually save you more than minification alone, and the two aren't mutually exclusive — do both.

None of this is exotic. It's a serializer setting, an output flag, or in the worst case a five-minute script — the kind of change that's easy to skip because it never feels urgent, right up until someone finally looks at what's actually going over the wire.

Markdown isn't just for documentation—it's the backbone of clean, portable, and AI-friendly content. Learn the essential Markdown best practices every developer should follow, plus the tools that help enforce consistency and save time.

99Tools — Mon, 22 Jun 2026 14:18:50 +0000

99Tools

Jun 22

Markdown Best Practices Every Developer Should Know (And Tools to Enforce Them)

#markdown #webdev #productivity #beginners

7 min read

Markdown Best Practices Every Developer Should Know (And Tools to Enforce Them)

99Tools — Mon, 22 Jun 2026 14:17:09 +0000

You already know Markdown.

You use it every day — in README files, GitHub issues, pull requests, documentation, and blog posts. It's everywhere in the developer world.

But here's the thing: most developers write functional Markdown. It renders. It works. But it's not always clean, consistent, or easy for teammates to read in its raw form.

And raw readability matters more than people realise. Your teammates read it in code review. Your future self reads it six months later. CI tools parse it. Inconsistent formatting causes real problems — broken renders, messy diffs, and documentation that slowly becomes a mess to maintain.

This guide covers the Markdown practices that actually make a difference. Not just the basics — but the specific habits that separate good documentation from great documentation.

Let's get into it.

Why Markdown formatting standards matter

Before diving in, let me explain why this is worth caring about.

Markdown has no single universal specification that all tools agree on. GitHub uses GitHub Flavored Markdown (GFM). VS Code defaults to CommonMark. dev.to has its own rendering quirks. Notion handles things differently again.

The same .md file can render differently depending on where you open it.

The best defence against this? Write clean, consistent, unambiguous Markdown. Follow the conventions. Use tools to enforce them.

It's the same reason we use Prettier for JavaScript. You stop thinking about formatting and just write — the tooling handles the rest.

1. Use ATX-style headings (with a space after #)

There are two heading styles in Markdown. ATX uses # symbols. Setext uses underlines (=== or ---).

Always use ATX. It's cleaner, more readable, and supported everywhere.

<!-- ✅ Do this -->
## My Section Heading

<!-- ❌ Not this -->
My Section Heading
------------------

Also — always put a space between the # and your heading text. Some parsers require it. Others don't. But the space is specified in the CommonMark spec, so it's the safest habit.

<!-- ✅ Correct -->
## Introduction

<!-- ❌ Risky -->
##Introduction

One more rule: never skip heading levels. Go H1 → H2 → H3 in sequence. Jumping from H1 directly to H4 breaks screen readers and makes your document structure confusing to navigate.

2. Always specify a language in fenced code blocks

Whenever you write a fenced code block, add a language identifier.

<!-- ✅ Do this -->

javascript
const greet = (name) => Hello, ${name}!;


<!-- ❌ Not this -->

javascript
const greet = (name) => Hello, ${name}!;

markdown

Why does it matter?

Syntax highlighting activates
Readers immediately know what they're looking at
Documentation generators use it for formatting and indexing
Screen readers can announce the language type

Common language identifiers: javascript, typescript, python, bash, json, yaml, sql, css, html, go, rust.

Use lowercase by convention. javascript is standard. JavaScript works in most parsers, but it's not consistent.

3. Keep list markers consistent

Unordered lists accept -, *, or + as markers. Pick one and use it throughout the entire document.

The most widely recommended choice is -.

<!-- ✅ Consistent — do this -->
- First item
- Second item
- Third item

<!-- ❌ Inconsistent — avoid this -->
- First item
* Second item
+ Third item

Mixing markers isn't just visually messy. Some parsers treat different markers as separate lists entirely, which breaks the rendered output.

For ordered lists, use 1. for every item rather than incrementing manually. If you insert or reorder items later, the numbering stays correct automatically.

<!-- ✅ Easier to reorder -->
1. Install dependencies
1. Configure the environment
1. Start the server

<!-- Rendered output is still: 1, 2, 3 -->

4. Add blank lines around block elements

This is one of the most common mistakes in Markdown files. Block elements — headings, code blocks, lists, blockquotes — need blank lines before and after them.

Without blank lines, some parsers get confused and produce unexpected output.

<!-- ❌ Missing blank lines — risky -->
Here's some intro text.
## Section Heading
More text here.
- Item one
- Item two
Some conclusion.

<!-- ✅ Properly spaced -->
Here's some intro text.

## Section Heading

More text here.

- Item one
- Item two

Some conclusion.

The raw file becomes far more readable too. When someone scans a .md file in a terminal or basic text editor, the spacing makes the structure obvious at a glance.

5. Write descriptive link text — not "click here"

This is a writing best practice as much as a Markdown one. But it shows up constantly in developer docs.

<!-- ❌ Tells the reader nothing -->
For more information, [click here](https://example.com/docs).

<!-- ✅ Tells the reader exactly where they're going -->
See the [official API documentation](https://example.com/docs) for details.

Descriptive link text matters for three reasons:

Accessibility — screen readers announce link text out of context. "Click here" is meaningless when read aloud in a list of links.
SEO — anchor text signals to search engines what the linked page is about.
Scannability — readers can understand the link's destination without stopping to click it.

Make your link text describe the destination, not the action.

6. Wrap technical terms in inline code

Any time you mention a function name, variable, file path, command, or technical term in prose — wrap it in backticks.

<!-- ❌ Technical terms blend into the text -->
Run npm install in the root directory, then open the config.js file.

<!-- ✅ Technical terms stand out immediately -->
Run `npm install` in the root directory, then open `config.js`.

This is one of those small habits that has a big impact on readability. Technical terms pop out visually. Readers can immediately tell "this is something I need to type or pay attention to" versus surrounding explanation.

7. Use blockquotes for the right things

Blockquotes are for quoting external content, adding important notes, or creating callouts. They're not for indentation or visual decoration.

<!-- ✅ Good use — an actual callout -->
> **Note:** This configuration only applies to production environments.

<!-- ❌ Misuse — this is just prose, not a quote -->
> This section explains how to set up your project.

On GitHub, you can use the alert syntax for proper callout blocks. It's more semantic and renders with distinct styling:

> [!NOTE]
> Highlights information the reader should take into account when skimming.

> [!WARNING]
> Critical content that demands immediate attention.

> [!TIP]
> Optional information to help the reader be more successful.

These render as styled, colour-coded callout boxes on GitHub — much cleaner than the old bold-in-a-blockquote approach. Use them in README files and documentation pages.

8. Align table pipes for raw readability

Markdown tables are notoriously awkward to write by hand. The pipes rarely line up, and the raw file becomes painful to read.

<!-- ❌ Valid, but hard to read in raw form -->
|Name|Role|Status|
|--|--|--|
|Alice|Developer|Active|
|Bob|Designer|Active|

<!-- ✅ Clean and readable even before rendering -->
| Name  | Role      | Status |
|-------|-----------|--------|
| Alice | Developer | Active |
| Bob   | Designer  | Active |

Both render identically. But the second version is readable in a code review, a terminal, or a plain text editor — places where your Markdown lives before it gets rendered.

Aligning pipes manually every time is tedious. A Markdown formatter does it instantly — paste your document in, get back clean, consistently formatted Markdown with aligned tables, proper spacing, and normalised list markers.

9. Use reference-style links for long URLs

When URLs are long, inline links clutter the prose and make it hard to read.

<!-- ❌ The URL overwhelms the sentence -->
See the [deployment guide](https://docs.example.com/guides/production/deployment/advanced-configuration?tab=docker&version=v3) before going live.

<!-- ✅ The prose stays clean -->
See the [deployment guide][deploy] before going live.

[deploy]: https://docs.example.com/guides/production/deployment/advanced-configuration?tab=docker&version=v3

Reference-style links work like footnotes. The prose reads naturally, and all the URLs sit at the bottom of the file where they're easy to update without touching the text.

This pays off especially in long documentation files where the same link appears multiple times.

10. End files with a single newline

This one's subtle but matters for git hygiene.

Every text file — including .md files — should end with exactly one newline character. Most editors do this automatically, but not all.

Without a trailing newline:

Git shows a \ No newline at end of file warning in diffs
Diffs become noisy in pull requests
Some POSIX tools behave unexpectedly when reading the file

In VS Code, enable this automatically with "files.insertFinalNewline": true in your settings. Most other editors have an equivalent option.

Tools that enforce all of this automatically

Reading these practices is useful. Remembering every single one while you're writing — less so.

The practical move is to integrate enforcement into your workflow so you don't have to think about it.

For teams and CI pipelines:

markdownlint — the most widely used Markdown linter. Available as a CLI, a VS Code extension, and a GitHub Action. Enforces rules like heading hierarchy, code block languages, and list consistency. Configurable with a .markdownlint.json file.
Prettier — if your team already runs Prettier on code, it handles Markdown too. Good for enforcing consistent prose wrapping and spacing.
remark — a powerful Markdown processor with a rich plugin ecosystem. Useful when you need to both lint and programmatically transform Markdown files.

For individual workflow:

The fastest option is to run your Markdown through a formatter before you commit or publish. It catches the things you'd otherwise miss — a missed blank line, an unspecified code block language, misaligned table pipes — without requiring any setup.

Quick reference

Practice	What to do
Headings	ATX style (`#`), space after `#`, don't skip levels
Code blocks	Always specify the language identifier
Lists	Use `-` for unordered; `1.` for all ordered items
Spacing	Blank lines before and after all block elements
Links	Descriptive anchor text, not "click here"
Inline code	Backticks for all technical terms, commands, filenames
Blockquotes	Only for actual quotes or callouts
Tables	Align pipes so the raw file is readable
Long URLs	Reference-style links to keep prose clean
File ending	One trailing newline character

Final thoughts

Markdown is deceptively simple. The basics take minutes to learn. But clean, consistent Markdown — readable in both raw and rendered form — takes deliberate habits.

The good news: most of this can be automated. Add markdownlint to your editor. Set up a GitHub Action to check Markdown on every pull request. Run docs through a formatter before you publish.

Set the standard once. Enforce it automatically. Then spend your energy on writing content worth reading.

What Markdown practices has your team standardised on? Drop a comment — I'd love to know what's working.

DEV Community: 99Tools

A practical guide to CSS gradients beyond the basics — angles explained properly, repeating patterns, fixing the "muddy middle" with oklch interpolation, real gradient animation with @property, and mesh gradients. Code examples throughout.

CSS Gradients: The Complete Guide

CSS Gradients: The Complete Guide

The three gradient types, at a glance

Linear gradients: the angle math nobody explains

Multiple color stops

Hard stops (no blending)

Radial gradients

Conic gradients

Repeating gradients (the part most tutorials skip)

Transparency: fading into nothing

Fixing the "muddy middle" problem: color-space interpolation

Gradient text

Gradient borders

Animating gradients, properly

Mesh gradients

Practical checklist before you ship a gradient

Wrapping up

CSV to JSON looks easy until BOMs, leading zeros, quoted commas, and ragged rows show up. Tested Python & Node code for the edge cases that actually break production scripts.

CSV to JSON: The Parts Nobody Mentions Until Your Script Breaks in Production

CSV to JSON: The Parts Nobody Mentions Until Your Script Breaks in Production

Why "just split on commas" doesn't work

A solid baseline: Python

Everything in CSV is a string, and that's a trap

The encoding problem you'll hit eventually

Delimiters aren't always commas

Node.js version, with a real streaming parser

When the file is too big to hold in memory

Handling malformed rows without crashing the whole job

Turning flat columns into nested JSON

Ragged rows and duplicate headers

Bonus: inferring a schema from the CSV itself

Quick, one-off conversions without writing code

A checklist for production conversions

JSON.stringify() seems simple—until real-world data gets messy. This guide covers the edge cases developers actually hit in production, from undefined and BigInt to circular references, nested JSON, escaping, and stable key order.

JSON to String Conversion: The Edge Cases That Actually Bite in Production

JSON to String Conversion: The Edge Cases That Actually Bite in Production

The baseline

Problem 1: Values that quietly disappear

Problem 2: Values that silently change

Problem 3: Circular references

Controlling serialization on purpose

toJSON()

The replacer function

The reviver function (parsing back)

Formatting: compact vs. readable

Embedding a JSON string inside something else

Inside an HTML <script> tag

JSON inside JSON

Key order isn't guaranteed the way you might assume

Cross-language interop: the differences bite in production

A quick checklist

Further reading

Think JSON.stringify() is simple? Think again. Learn how JSON to String conversion really works, avoid common mistakes, handle edge cases, and write cleaner JavaScript with practical examples you can use today.

JSON to String in JavaScript: The Complete Guide (And the Gotchas That Bite Even Experienced Devs)

JSON to String in JavaScript: The Complete Guide (And the Gotchas That Bite Even Experienced Devs)

TL;DR

First, Let's Clear Up the Terminology

The Wrong Way (and Why It Fails)

The Core Method: JSON.stringify()

Making Output Readable: The Indentation Argument

Controlling What Gets Included: The Replacer

Custom Serialization With toJSON()

Where You'll Actually Use This

Storing Data in localStorage or sessionStorage

Sending Data With fetch()

Logging and Debugging

Comparing or Hashing Objects

The Gotchas (Learned the Hard Way)

Some Values Just Disappear

NaN and Infinity Become null

Circular References Throw

BigInt Isn't Supported — At All

Date Serializes Cleanly, But Doesn't Come Back the Same Way

Map, Set, and Class Instances Don't Serialize the Way You'd Expect

Key Order Isn't Always What You Typed

The Security Gotcha Nobody Mentions

The "Quick Deep Clone" Trick Has Real Limits

Going the Other Direction: JSON.parse()

`toJSON()`

Inside an HTML `<script>` tag

The Core Method: `JSON.stringify()`

Custom Serialization With `toJSON()`

Storing Data in `localStorage` or `sessionStorage`

Sending Data With `fetch()`

`NaN` and `Infinity` Become `null`

`BigInt` Isn't Supported — At All

`Date` Serializes Cleanly, But Doesn't Come Back the Same Way

`Map`, `Set`, and Class Instances Don't Serialize the Way You'd Expect

Going the Other Direction: `JSON.parse()`

Always Wrap It in `try/catch`

`JSON.stringify()` vs. the Alternatives

3. The `/g` flag is stateful, and that will bite you