DEV Community: 99Tools

Messy LESS hiding bugs in your stylesheets? Here’s a practical guide to beautifying LESS in seconds, with real before/after examples, nesting tips, and a free online tool to clean up your code fast.

99Tools — Sun, 18 Oct 2026 04:53:05 +0000

99Tools

Oct 18

Stop Squinting at Messy LESS: How to Beautify Your Stylesheets in Seconds

#webdev #css #tutorial

5 min read

Stop Squinting at Messy LESS: How to Beautify Your Stylesheets in Seconds

99Tools — Sun, 18 Oct 2026 04:51:57 +0000

We've all been there. You inherit a project, open styles.less, and it looks like someone typed the whole thing in a single breath. Nested rules collapsed onto one line, mixins with no spacing, variables jammed against their values.

You can still read it. But every minute you spend decoding formatting is a minute you're not fixing the actual bug.

In this post I'll walk through what LESS is (quickly), why formatting matters more than people admit, and how a LESS beautifier can clean up a file in seconds. I'll also show you real before and after examples so you can judge for yourself.

Quick refresher: what is LESS?

LESS is a CSS preprocessor. It extends plain CSS with features like variables, nesting, mixins, functions and operations, then compiles down to regular CSS that browsers understand. The official LESS documentation is the best place to go deep on the language itself.

A tiny taste:

@primary: #3b82f6;

.button {
  background: @primary;

  &:hover {
    background: darken(@primary, 10%);
  }
}

That nesting and the darken() function are what make LESS pleasant to write. But they're also what make badly formatted LESS painful to read, because the structure is the logic.

Why formatting matters more in LESS than in plain CSS

In plain CSS, a messy file is annoying. In LESS, a messy file can actually hide bugs. Here's why:

Nesting depth is meaning. A rule nested one level too deep (or too shallow) changes the compiled selector. If indentation doesn't match nesting, you can't see the mistake.
Mixins and guards are easy to miss. A mixin call buried in a long line is easy to overlook when you're debugging why a style is applied.
Missing braces are brutal. One unclosed } in a deeply nested block can break compilation, and the error message often points somewhere unhelpful.
Code review gets noisy. If every developer formats differently, pull requests fill up with whitespace changes that hide the real ones.

Consistent formatting isn't about being picky. It's about making the structure of your styles visible at a glance.

What does a LESS beautifier actually do?

A beautifier takes your LESS code and rewrites its whitespace and layout without changing what it means. Typically that includes:

Consistent indentation for nested blocks
One declaration per line
Sensible spacing around colons, braces and operators
Line breaks between rules so blocks are easy to scan

Crucially, it should not change your logic. Variables, mixins, operations and nesting stay exactly as you wrote them. Only the presentation changes.

A real before and after

Here's the kind of LESS you might get from a quick copy-paste, a minified export, or a teammate in a hurry:

@primary:#3b82f6;@radius:6px;
.mixin-card(@pad:16px){padding:@pad;border:1px solid #eee}
.btn{color:#fff;background:@primary;border-radius:@radius;&:hover{background:darken(@primary,10%)}.icon{margin-right:4px}}
.card{.mixin-card(24px);h2{font-size:1.25rem;a{color:@primary}}}

Technically valid. Practically unreadable. Now the same code after running it through a beautifier:

@primary: #3b82f6;
@radius: 6px;

.mixin-card(@pad: 16px) {
  padding: @pad;
  border: 1px solid #eee;
}

.btn {
  color: #fff;
  background: @primary;
  border-radius: @radius;

  &:hover {
    background: darken(@primary, 10%);
  }

  .icon {
    margin-right: 4px;
  }
}

.card {
  .mixin-card(24px);

  h2 {
    font-size: 1.25rem;

    a {
      color: @primary;
    }
  }
}

Same code, same output once compiled, but now you can see that .icon lives inside .btn, that .card calls the mixin, and that the link color sits three levels deep. That last one is a good reminder to watch your nesting depth, which you'd never notice in the single-line version.

How to use an online LESS beautifier

When I just need to clean up a snippet or a single file, I don't want to configure a toolchain. An online tool is the fastest path. I put together the LESS Beautifier on 99tools for exactly this situation. The workflow is simple:

Paste your messy LESS into the input box.
Run the beautifier.
Copy the cleaned-up result back into your editor.

No install, no config file, no setup. It's handy when you're:

Reviewing LESS from a client or a legacy project
Cleaning a snippet before sharing it in a bug report or Stack Overflow question
Reading code that was minified or exported from another tool
Teaching or learning LESS and wanting readable examples

A quick tip: as with any online tool, don't paste proprietary code or anything containing secrets if your company policy says otherwise. For sensitive projects, use a local formatter instead (more on that below).

Beautifier vs. linter vs. compiler

These three get confused a lot, so here's the short version:

Tool	What it does	Changes your code?
Beautifier / formatter	Fixes indentation, spacing and layout	Whitespace only
Linter	Flags problems and style violations	Usually no (some auto-fix)
Compiler (`lessc`)	Turns LESS into CSS	Produces new output

A beautifier won't catch a typo in a variable name, and it won't tell you your nesting is too deep. Use it alongside a linter like Stylelint and your normal compile step, not instead of them.

Best practices for clean LESS

Formatting is the baseline. Here are a few habits that keep LESS maintainable once it's tidy:

Keep nesting to 3 levels or fewer. Deep nesting creates overly specific selectors that are painful to override.
Group variables at the top or in a dedicated file so theme changes happen in one place.
Name mixins clearly and keep them small and single-purpose.
Agree on one style as a team (2 spaces vs 4, blank lines between rules) and automate it so nobody argues in code review.
Run a formatter before committing, so diffs show real changes only.

When an online tool isn't the right fit

I want to be upfront: an online beautifier is great for quick jobs, but it isn't the answer to everything.

If your team formats code on every commit, you'll be better served by an automated local setup, such as Prettier, which supports LESS, wired into your editor or a pre-commit hook. And if you're starting a brand new project, it's also worth knowing that native CSS now supports nesting, which covers some of what people originally reached for preprocessors to do. The MDN guide to CSS nesting is a good overview if you're weighing your options.

That said, LESS is still used in plenty of real projects, and a lot of us are maintaining it for years to come. For those moments, having a quick way to make messy code readable is genuinely useful.

Wrapping up

Readable code isn't a luxury. It's how you spot bugs sooner, review faster, and onboard people without a lecture. A LESS beautifier takes about ten seconds and removes one whole category of friction.

If you have a messy .less file sitting around, try the LESS Beautifier on it and see how the structure changes. And if you've got your own tips for keeping LESS clean, or a horror story from a legacy stylesheet, drop it in the comments. I'd love to hear it.

Happy styling! 🎨

I benchmarked Bootstrap through 3 CSS minifiers. Minifying cut ~17% of the raw size, but gzip alone cut ~88%. Real numbers, before/after examples, common gotchas, and a script to reproduce it on your own CSS.

99Tools — Mon, 28 Sep 2026 06:51:29 +0000

99Tools

Sep 28

I Minified Bootstrap 3 Ways. Here's What CSS Minification Really Saves

#css #webdev

5 min read

I Minified Bootstrap 3 Ways. Here's What CSS Minification Really Saves

99Tools — Mon, 28 Sep 2026 05:12:54 +0000

Everyone says "minify your CSS." Almost nobody says how much it actually helps, especially if your server already compresses files.

So I ran the numbers instead of repeating the advice. Some of the results changed how I think about it.

First, what does a minifier actually do?

It rewrites your CSS into a smaller but equivalent form: no comments, no whitespace, shorter values. Here's a deliberately messy stylesheet I used to test three popular minifiers (419 bytes):

/* Card component */
.card {
  margin: 0px;
  padding: 16px 16px 16px 16px;
  background-color: #ffffff;
  color: rgba(0, 0, 0, 1);
  border: 1px solid #cccccc;
}

.card-title { font-weight: bold; margin: 0px; }
.card:hover { background-color: #f5f5f5; }
.card-title { font-size: 1.25rem; }

.btn     { color: #ffffff; background-color: #0066ff; }
.btn-alt { color: #ffffff; background-color: #0066ff; }

And what cssnano produced (234 bytes, about 44% smaller):

.card{margin:0;padding:16px;background-color:#fff;color:#000;border:1px solid #ccc}.card-title{font-weight:700;margin:0}.card:hover{background-color:#f5f5f5}.card-title{font-size:1.25rem}.btn,.btn-alt{color:#fff;background-color:#06f}

Look at what happened beyond whitespace:

0px became 0
padding: 16px 16px 16px 16px became 16px
#ffffff became #fff, and rgba(0,0,0,1) became #000
bold became 700
.btn and .btn-alt were merged into one rule

Lightning CSS gave the same size (234 bytes). clean-css at its defaults gave 282 bytes: it left padding: 16px 16px 16px 16px alone and kept .btn and .btn-alt separate. So minifiers aren't identical.

Also notice the two .card-title rules weren't merged by any tool. That's on purpose. Lightning CSS's docs explain it only merges adjacent rules, because merging others could change the cascade order and break styles. Good minifiers are conservative about anything that could change behavior.

The benchmark: Bootstrap through 3 minifiers

Toy examples are fun, but let's use a real stylesheet. I took the unminified bootstrap.css from Bootstrap 5.3.3 (281,005 bytes) and ran it through three minifiers (cssnano 8.0.10, Lightning CSS 1.33.0, clean-css 5.6.3). Then I measured raw size, gzip (level 9) and Brotli (quality 11):

	Raw	gzip	Brotli
Original	281,005 B	32,807 B	24,509 B
cssnano	231,970 B (−17.5%)	30,975 B (−5.6%)	22,984 B (−6.2%)
Lightning CSS	229,303 B (−18.4%)	30,580 B (−6.8%)	22,650 B (−7.6%)
clean-css	232,757 B (−17.2%)	30,800 B (−6.1%)	22,750 B (−7.2%)

What the numbers say

1. Minification alone: about 17-18% smaller. Solid, and nearly free.

2. Compression is the real hero. Gzip alone shrinks the original file by about 88%, and Brotli by about 91%. Minification alone gets you 17%. If your server isn't compressing text, fix that first.

3. On top of compression, minification saves roughly 1.5-2.2 KB here. That's a smaller win than the raw numbers suggest, because gzip and Brotli already crush repeated whitespace and indentation. The gain is real but modest.

4. The three tools landed within about 1.5 percentage points of each other on this file. Pick based on your stack, not on a tiny size difference.

Caveats: this is one file, and Bootstrap's source is already tidy. Messier CSS (lots of comments, duplicated rules) will shrink more. I also used max compression levels; many servers use lower ones, so real-world differences can be a bit larger.

So is it worth it? Yes, and here's when it matters most

Servers/hosts without compression. Raw size is what users download, and here minification saves about 50 KB on this file.
Places where compression doesn't apply, like some email setups and embedded snippets.
Free wins add up. 2 KB on a stylesheet is small, but you get it with zero code changes.
Cleaner output for free, like merged rules and shortened values, without touching your source.

The takeaway: minify and compress, but don't expect miracles from minification alone. If you want to understand why this matters for performance, Chrome's Lighthouse docs on minifying CSS walk through it. They also note that Lighthouse's savings estimate is conservative, since real minifiers do smarter optimizations than just stripping whitespace.

How to minify: two paths

The quick path (no setup). Working on a small site, a client fix, or a one-off file? Paste your CSS into a free online CSS minifier, copy the result, done. It's also a handy way to sanity-check how much a file would shrink before you decide to automate anything.

The automated path. For real projects, put it in your build so you never forget:

Modern tools like Vite, Parcel, Next.js and others minify CSS in production builds (check your version's docs for the exact defaults)
webpack needs a plugin like css-minimizer-webpack-plugin for this
Or run a CLI yourself with PostCSS + cssnano, Lightning CSS, or clean-css

A PostCSS + cssnano one-liner:

npx postcss input.css -u cssnano --no-map -o output.min.css

Don't skip these gotchas

Keep source maps on. Debugging a one-line CSS file is miserable. Both Lightning CSS (--sourcemap) and clean-css (--source-map) can generate one, so DevTools shows your original code.

Never edit the minified file. Keep styles.css as the source of truth and generate styles.min.css from it.

Test after changing your setup. Minifiers are safe by design, but tools differ. In my demo, Lightning CSS even reordered independent declarations (harmless there). Give the site a quick visual check.

Watch your browser targets. Some tools (Lightning CSS especially) can transform modern syntax based on your target browsers, so check your config.

Try it yourself in 2 minutes

Don't trust my numbers, reproduce them:

mkdir css-bench && cd css-bench && npm init -y
npm i bootstrap@5.3.3 cssnano postcss postcss-cli lightningcss-cli clean-css-cli

sed '/sourceMappingURL/d' node_modules/bootstrap/dist/css/bootstrap.css > orig.css
npx postcss orig.css -u cssnano --no-map -o cssnano.min.css
npx lightningcss --minify orig.css -o lightning.min.css
npx cleancss -o cleancss.min.css orig.css

for f in orig cssnano.min lightning.min cleancss.min; do
  echo "$f: raw=$(wc -c < $f.css) gzip=$(gzip -9 -c $f.css | wc -c)"
done

Even better, run your own stylesheet through it and compare. You can also drop it into the online minifier and see how it stacks up. Then open DevTools → Network, and check the content-encoding header to confirm your server is compressing (br or gzip).

Quick checklist

[ ] Production build outputs minified CSS
[ ] Gzip or Brotli is enabled (this is the bigger win!)
[ ] Source maps are on if you need production debugging
[ ] Source CSS stays readable in your repo
[ ] You did a quick visual check after changing the setup

Wrapping up

CSS minification won't transform your site by itself, but it's a free, low-risk improvement, and it works best alongside compression. Now you have real numbers to back it up.

What's your setup: cssnano, Lightning CSS, or whatever your bundler ships? And did you get different results on your own CSS? Tell me in the comments. 👇

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.

DEV Community: 99Tools

Messy LESS hiding bugs in your stylesheets? Here’s a practical guide to beautifying LESS in seconds, with real before/after examples, nesting tips, and a free online tool to clean up your code fast.

Stop Squinting at Messy LESS: How to Beautify Your Stylesheets in Seconds

Stop Squinting at Messy LESS: How to Beautify Your Stylesheets in Seconds

Quick refresher: what is LESS?

Why formatting matters more in LESS than in plain CSS

What does a LESS beautifier actually do?

A real before and after

How to use an online LESS beautifier

Beautifier vs. linter vs. compiler

Best practices for clean LESS

When an online tool isn't the right fit

Wrapping up

I benchmarked Bootstrap through 3 CSS minifiers. Minifying cut ~17% of the raw size, but gzip alone cut ~88%. Real numbers, before/after examples, common gotchas, and a script to reproduce it on your own CSS.

I Minified Bootstrap 3 Ways. Here's What CSS Minification Really Saves

I Minified Bootstrap 3 Ways. Here's What CSS Minification Really Saves

First, what does a minifier actually do?

The benchmark: Bootstrap through 3 minifiers

What the numbers say

So is it worth it? Yes, and here's when it matters most

How to minify: two paths

Don't skip these gotchas

Try it yourself in 2 minutes

Quick checklist

Wrapping up

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)

`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