DEV Community: zhihu wu

Why Your Diff Shows Every Line Changed (And It's Not Your Code)

zhihu wu — Sat, 26 Sep 2026 13:02:11 +0000

You open a pull request. You changed one line. The diff is 412 lines.

You blame the linter, then yourself. Usually it's neither. A diff compares characters before it compares meaning, and the characters that changed are invisible.

1. Line endings: CRLF vs LF

The classic culprit. A file written on Linux ends its lines with \n; a file written on Windows ends them with \r\n. Git stores bytes, so the moment a teammate's editor (or a script, or a Windows tool) rewrites the file with the other convention, every single line differs by one byte you cannot see.

To confirm it, run git diff --ignore-cr-at-eol. If the 412-line diff collapses to your one real change, that's your answer. When the two versions are not in git yet — two config files, two API response dumps — I paste both into the Diff Checker and flip the "ignore whitespace" toggle. It runs entirely in the browser, so pasting a private config is not a concern.

2. Trailing whitespace

Editors with "trim trailing whitespace on save" enabled rewrite every line they touch, and any formatter run rewrites the whole file. You get lines marked as changed that look byte-identical, because the difference sits at the end, past where your eye stops rendering.

3. Tabs vs spaces, and indent conversion

One contributor's editor converts indentation on save. Every nested block now reads as "modified". git diff -w (ignore all whitespace) collapses it instantly — and if it does, you know the change is cosmetic.

4. Encoding and BOM

A BOM added by a Windows editor, or a latin-1 → UTF-8 rewrite, changes every line containing a non-ASCII character. file on both versions tells you the encoding, and a suspiciously huge git diff --stat on a mostly-ASCII file is the hint.

The habit that fixes it permanently

.gitattributes with * text=auto eol=lf normalizes line endings at commit time, once, for everyone.
.editorconfig with end_of_line = lf, insert_final_newline = true, trim_trailing_whitespace = true so every editor agrees on the rules.
Review with git diff -w before you push. If the diff disappears, the change is whitespace-only: revert it or commit it on its own, so the real change stays reviewable.

A diff never lies — it compares characters. When its report looks impossible, check the invisible ones first: end-of-line bytes, trailing spaces, indentation, encoding. A whitespace-aware diff view is the fastest way to stop guessing and get back to your actual change.

A Day Is Not 86400 Seconds: The DST Bug in Your Date Math

zhihu wu — Thu, 24 Sep 2026 13:02:29 +0000

Most "date bugs" I've had to chase in production weren't off by a timezone. They were off by exactly one day, and they only appeared twice a year.

The bug

// "tomorrow, same time"
const tomorrow = new Date(Date.now() + 86400 * 1000);

That code is correct 363 days a year. On the other two it is off by an hour, and if you round the result down to a date it is off by a whole day.

The epoch is absolute; calendar units are not

A Unix timestamp is a fixed instant. 1758700800 is the same moment in Lagos, Lisbon and Lima - only the rendered local time differs. Arithmetic in seconds is therefore always exact in absolute time, and that is the trap: "one day later" is not an absolute duration. It is a calendar operation whose length depends on the timezone rules in effect at both moments.

A spring-forward day is 82,800 seconds long; a fall-back day is 90,000. Add exactly 86,400 seconds to local midnight and you land at 01:00 (already past the boundary you wanted) or at 23:00 of the day before.

Same bug, four languages

// adds exactly 86400 s - wrong across a DST boundary
Instant.now().plus(Duration.ofDays(1));
// calendar-aware - what you usually mean
ZonedDateTime.now(zone).plusDays(1);

new Date(Date.now() + 86400 * 1000);              // +86400 s exactly
const d = new Date(); d.setDate(d.getDate() + 1); // one calendar day

Go's t.Add(24 * time.Hour) is a duration; t.AddDate(0, 0, 1) is a calendar day. In SQL, date_add(d, interval 1 day) follows the zone while d + interval 86400 second does not. Python is the sneakiest: dt + timedelta(days=1) is wall-clock arithmetic on naive datetimes, but adding timedelta to an aware datetime in DST-aware zones can still surprise you.

What actually fixes it

Store the absolute instant - epoch seconds or UTC ISO 8601. Timestamps do not have DST.
Make "which calendar day is this?" decisions in the user's timezone (the zone, not an offset: an offset is a snapshot, a zone is a rule set with a history).
For "yesterday's rows", compute the day boundaries as calendar days in that zone and convert those boundaries to instants - instead of subtracting 86400 from now.
Put a DST date in your test suite. Twice a year is exactly often enough to forget.

When one of these bites, the first move is converting the raw epoch values in the logs to local time. I use the timestamp converter on CodeToolbox for that - it shows local and UTC side by side and auto-detects seconds vs milliseconds, which is the other half of this bug family, and it runs entirely in the browser so staging log values never leave the machine.

Why the Same Markdown Renders Differently on GitHub, Dev.to, and Notion

zhihu wu — Mon, 21 Sep 2026 13:02:35 +0000

You write | Name | Role | with a clean separator row, commit, and open the README. On GitHub it's a tidy table. In your team's docs site it's a wall of pipes. Same file, same lines, different renderer.

That's not a bug in your Markdown. "Markdown" stopped being one language years ago.

The three dialects you hit every week

CommonMark — the spec. Headings, lists, emphasis, links, code blocks, blockquotes, and not much else. If a renderer says "strict Markdown," this is what it means.

GFM (GitHub Flavored Markdown) — CommonMark plus tables, task lists, strikethrough, autolinked URLs, and footnotes. GitHub uses it. So does Dev.to, most static site generators (Jekyll, Hugo, MkDocs with the right plugin), and marked.js with remark-gfm in the JavaScript ecosystem.

Editor dialects — Notion, Obsidian and friends add callouts, [[wikilinks]], highlight marks and databases. They export Markdown, but the round trip is lossy: a Notion callout becomes a plain paragraph the moment it lands in someone else's editor.

Where the divergence actually bites

Tables. GFM only. Without it, you get raw pipes.
Task lists. - [x] renders as a checkbox on GitHub; elsewhere it's the literal text [x].
Emoji shortcodes. :shipit: needs an emoji plugin. Core parsers leave it alone — paste the real character instead.
Line breaks. A single newline is a space in CommonMark. GitHub behaves the same way, which is why "my newline does nothing" is usually correct behavior rather than a broken preview.
Heading anchors. GitHub slugifies headings into anchors (## Setup Guide becomes #setup-guide). Other renderers generate different slugs, so cross-links break silently.

The practical habit is to write for the smallest common subset: assume CommonMark plus tables and task lists, and treat everything else as platform-specific sugar. Then verify before publishing — not in your editor, but in a renderer that matches your audience.

For that last step I keep a browser previewer open: it runs marked.js with GFM enabled (the same dialect GitHub and Dev.to use), renders as you type, and never uploads a byte — everything happens client-side. Here it is: Markdown Preview on CodeToolbox. Paste the file, confirm your tables and task lists survive the trip, then commit.

One minute of previewing beats a "fix README formatting" commit at 11pm.

Your JWT Is Not Encrypted - Here's What's Actually Inside It

zhihu wu — Sat, 19 Sep 2026 13:02:58 +0000

A JWT looks like encrypted gibberish: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIx.... Here is the uncomfortable part — it is not encrypted. Anyone holding the token can read everything in it. That is by design, and it is also why a surprising number of "why is auth broken?" bugs get solved in about ten seconds once you actually look inside the token.

Three segments, no secrets

A JWT is header.payload.signature, each part Base64URL-encoded, joined by dots. Base64URL is just an encoding (URL-safe alphabet, padding stripped so it can live in a header, cookie, or query string). The first two segments are plain JSON. The third is a signature over the first two — a signature proves nobody tampered with the token, it does not hide anything.

Decode one in Node, no dependencies:

const token = 'eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxIn0.abc123';
const [, payload] = token.split('.');
const claims = JSON.parse(Buffer.from(payload, 'base64url'));
console.log(claims);

Python:

import base64, json
payload = token.split('.')[1]
claims = json.loads(base64.urlsafe_b64decode(payload + '==='))

What to check when auth fails

Almost every JWT bug is one of these claims, and they are all Unix seconds:

exp — expiry. Expired tokens produce a 401 that has nothing to do with your code.
nbf — "not before". A token used too early is invalid, which bites when servers' clocks drift.
aud / iss — audience and issuer. One service rejecting a token issued for a different audience is extremely common in multi-service setups.

Convert exp and compare against the clock before you start rewriting middleware.

The bug that is not a bug: alg: none

The header carries alg, and the single worst JWT mistake is letting the client tell the server which algorithm to trust. If a server honours "alg": "none", an attacker deletes the signature and forges any payload they want. A subtler variant is algorithm confusion: an RS256 token re-signed as HS256 using the public key as the HMAC secret. Fix both by pinning the accepted algorithms server-side and always verifying with a real library (jose, PyJWT, jsonwebtoken) — never by decoding and trusting.

Don't put anything private in the payload

Roles, internal IDs, emails, feature flags — all readable by whoever holds the token, including anyone who finds it in a log or a URL. Keep the payload minimal; look up the rest server-side.

When I'm debugging one of these, I decode the token first. I've been using CodeToolbox's JWT decoder — it runs entirely in the browser (no token leaves your machine), prints the header and claims, and converts exp/iat/nbf into readable local time so I can see instantly whether the token is expired. It does not verify signatures, which is the honest limitation of any browser-side tool: verification needs the key and belongs on your server.

Token debugging tip of the day: read the claims before you touch the code. Most of the time, the token was simply expired.

Why Your Regex Returns true Then false on the Same Input

zhihu wu — Wed, 16 Sep 2026 13:01:44 +0000

You write a quick validation loop, run it, and get true, false, true, false for four identical strings. Nothing in the input changed. Nothing in the pattern changed. So what did?

The regex object is carrying state.

The hidden `lastIndex` property

When a pattern has the g flag, the returned RegExp object keeps a property called lastIndex — the position where the previous match ended. The next .test() or .exec() call starts searching from there instead of from zero. On a successful match lastIndex moves forward; on a failure it resets to 0. Because test() only hands you a boolean, that reset is invisible, and you see just the symptom: the same input reporting different results depending on what came before it.

It bites hardest in exactly the places regex lives longest — a module-level constant, a class field, a cached pattern inside a helper. A regex compiled inline inside a loop behaves fine because it gets thrown away after each pass.

Three ways to fix it

1. Compile fresh each time. A new regex object starts with lastIndex = 0:

function isHexColor(s) {
  return new RegExp('^#[0-9a-f]{6}$', 'i').test(s);
}

2. Reset it manually if you want to keep reusing one object for performance:

const HEX = /^#[0-9a-f]{6}$/i;

function isHexColor(s) {
  HEX.lastIndex = 0;
  return HEX.test(s);
}

3. Use matchAll() when you want every match. It returns an iterator and does not mutate the original pattern, so no index bookkeeping leaks into your logic:

const digits = [...'a1 b2 c3'.matchAll(/[a-z]([0-9])/g)].map(m => m[1]);

The sticky flag too

y (sticky) behaves the same way — it also anchors matching at lastIndex, and it does not reset on failure. If you assemble flag strings dynamically from user input or config, that state can survive far longer than you expect.

Rule of thumb: treat any g- or y-flagged regex as a stateful object. Either create one per use, or set lastIndex = 0 at the top of every call.

💡 When you are chasing this class of bug, seeing every match highlighted as you type beats sprinkling console.log through the file. I keep a regex tester open in a browser tab (there's a free one at codetoolbox.pro/tools/regex-tester.html) — it recompiles the pattern on each keystroke, shows capture groups side by side, and runs entirely in your browser, so nothing you paste in leaves your machine.

How Fast Can a GPU Crack Your Password? Let's Do the Math

zhihu wu — Mon, 14 Sep 2026 13:02:40 +0000

Every few months someone posts a "this password takes 3 billion years to crack" chart, and every few months it's wrong — not because the math is hard, but because the chart quietly assumes the site you're logging into stored your password the way it should have.

Here's the only equation that matters:

keyspace ÷ guesses per second = time

Both numbers are knowable. Let's fill them in.

What a single modern GPU actually does

Rough hashcat figures for one RTX 4090 — orders of magnitude are what matter here, not decimal places:

What's being attacked	Guesses per second
MD5	~100,000,000,000
NTLM (Active Directory, Windows)	comparable
bcrypt, cost 12	~20,000
Argon2id, sensibly tuned	a few thousand

That's a five-million-fold spread. Which hash a site uses changes the cracking time far more than an extra character does.

Three real answers

1. Eight lowercase letters and digits — 36^8 ≈ 2.8 trillion candidates.

Against bcrypt at 20,000/s: ~4.5 years on one GPU.
Against MD5 at 100 billion/s: ~28 seconds.

2. Four random words from a 7,776-word list — 7776^4 ≈ 3.7 quadrillion candidates.

Against bcrypt: ~5,800 years.
Against MD5: ~10 hours.

3. Rent ten GPUs and divide by ten. Cloud GPU is billed by the minute; nobody needs to own the hardware to run this.

What this actually tells you

Length is cheap, symbols are expensive. Going 8 → 12 characters costs the attacker thousands of times more; swapping a for @ multiplies keyspace by a handful. Passphrases buy more than leetspeak.
You cannot control the hash. You only find out what a service uses after it leaks. Assume worst case and make the keyspace big enough to survive it.
Online attacks are a different problem. Login forms are rate-limited, locked out, and often behind 2FA — the math above applies to an offline dump of hashes, which is how breaches actually burn people.
Reuse is the multiplier. One reused password turns one breach into twenty compromised accounts, no cracking required.

The boring habit that works

Generate 16+ random characters, unique per site, and let a password manager hold them. The only thing you need to remember is the manager's passphrase — and that one deserves the passphrase treatment, because it's the single key that unlocks everything else.

When I want to see the difference between my old 8-character habit and what a generator produces, I use CodeToolbox's password generator — it runs entirely in your browser with no network calls, and it shows the entropy estimate next to the output. Watching that number jump from ~40 bits to ~100+ just by picking length instead of complexity is a better teacher than any security blog post, including this one.

Pick length. Skip the symbol gymnastics.

The Contrast Ratio Bug Hiding in Your Color Palette

zhihu wu — Fri, 11 Sep 2026 13:01:35 +0000

Most accessibility bugs I've shipped were not missing alt text or broken keyboard order. They were colors.

A brand blue that looked fine in Figma, dropped onto a button, with white label text that nobody could read on a laptop at 40% brightness.

Contrast is a number, not a vibe

WCAG 2.1 defines contrast as a ratio between the relative luminance of two colors:

L = 0.2126 * R + 0.7152 * G + 0.0722 * B
contrast = (L1 + 0.05) / (L2 + 0.05)

R, G and B have to be linearized first (undo the sRGB gamma curve), which is why you cannot just average RGB values and call it done. The thresholds are 4.5:1 for normal text, 3:1 for large text (18px+, or 14px bold) and UI component boundaries.

Three traps that keep sailing through design review:

Gray body text. #999999 on white is about 2.8:1 and fails. #767676 is the lightest gray that still passes on white.
Colored text on a colored background. Dark blue on medium blue can measure 1.6:1 even though both colors clearly "look different."
Placeholder text. Usually the same light gray as trap 1, and it is text the user has to read to fill in the form.

HSL lightness lies to you

hsl(60, 100%, 50%) (yellow) and hsl(240, 100%, 50%) (blue) share an identical lightness value and have wildly different perceived brightness. That is because HSL lightness is a geometric property of the RGB cube, not a measure of how much light actually reaches your eye.

When you need a fast estimate, use perceived brightness:

Y = (0.299 * R + 0.587 * G + 0.114 * B) / 255

Above roughly 0.6 the background is light, so use dark text. Below 0.4, use white. The 0.4-0.6 band is where both options look muddy, and that is your signal to change the background instead of fighting it.

A 30-second workflow

Pick the background, read off the RGB values, and check the ratio before you hand off to QA. I use CodeToolbox's color picker (https://codetoolbox.pro/tools/color-picker.html) because it shows HEX, RGB and HSL side by side and updates live as you drag a slider, so you can nudge a color until it crosses the threshold without converting anything by hand. It runs entirely in your browser, no uploads, no signup.

Contrast is one of the few accessibility requirements you can satisfy completely and deterministically in a single commit. Might as well.

Unix Timestamps: The Seconds-vs-Milliseconds Bug That Wastes Hours

zhihu wu — Wed, 09 Sep 2026 13:09:25 +0000

Every developer has hit this at least once: a timestamp that renders as 1970-01-01 or, even weirder, as the year 5138. The system isn't broken — you're mixing seconds and milliseconds.

The core distinction

A Unix timestamp counts seconds since the epoch (1970-01-01 UTC). Seconds values are 10 digits (1728000000). Milliseconds values are 13 digits (1728000000000).

The trap: JavaScript, Java, and .NET natively produce milliseconds (Date.now()), while Go, Python, PHP, and nearly every database work in seconds. Pass a 13-digit value where 10 digits are expected and you've just asked the API to interpret a date 1000× too far in the future.

Where this bites in practice

JWT expiry. JWT claims carry exp and iat in seconds. Generate them with Date.now() + 3600000 instead of Math.floor(Date.now()/1000) + 3600 and your token expires... sometime around the year 5138, which most servers treat as already-expired or never-expiring depending on validation logic. Auth bugs that make no sense usually trace back here.

API timestamps. Many JSON APIs return raw Unix seconds. When debugging, logging "created_at": 1756789200 to a console that doesn't auto-format is useless — you have to convert it in your head or open a converter.

Database queries. MySQL's UNIX_TIMESTAMP() returns seconds; if your app layer sends milliseconds, your range queries silently return nothing for "today."

A fast mental check

Count the digits. 10 digits = seconds, 13 = milliseconds. If a value has 12 digits, it's almost certainly milliseconds from a truncated or rounded source — treat it with suspicion.

If a timestamp converts to a date in 1970, it's too small for milliseconds (someone divided by 1000, or it's genuinely seconds read as ms). If it lands in 5138, it's too big for seconds — a milliseconds value read as seconds.

The practical fix

Pick seconds as your wire format and be explicit about it: Math.floor(Date.now() / 1000) in JS, int(time.time()) in Python, time.Now().Unix() in Go. Never send raw Date.now() to a backend that expects seconds — write the division into a named helper so nobody "fixes" it later.

And when you're debugging a log line full of raw integers, a converter that handles auto-detection saves the day: paste the value, get both local and UTC time instantly. I keep CodeToolbox's Unix Timestamp Converter bookmarked for exactly this — it auto-detects seconds vs milliseconds, so the 1970/5138 confusion never even starts. It runs entirely in the browser, which matters when the timestamp you're debugging belongs to a customer's private data.

Got a timestamp horror story? The "5138 bug" and the "1970 bug" are the same mistake from opposite directions — drop yours in the comments.

5 Cron Gotchas That Silently Break Your Jobs (and How to Fix Them)

zhihu wu — Sun, 06 Sep 2026 13:04:02 +0000

Cron looks simple: five fields and a command. But some of its oldest quirks are exactly where jobs fail silently — usually at 3 AM when nobody is watching. Here are five gotchas I've hit (or watched teammates hit), with the fixes.

1. Day-of-month and day-of-week are OR, not AND

30 2 1 * 1 does NOT mean "the first of the month AND Monday." Cron fires the job if EITHER field matches — so this runs at 2:30 AM on the 1st of every month AND at 2:30 AM every Monday. To target a true "first Monday," keep the schedule simple and add a guard inside the command that checks the day of month is within the first 7 days.

2. Cron runs in the server's timezone, not yours

0 0 * * * means midnight in whatever timezone the host is set to. Docker containers default to UTC, and cloud VMs are often UTC too — so your "daily midnight" job can silently run at 8 AM your time. Check with the date command in the same environment, and use CRON_TZ if your cron implementation supports it.

3. The percent sign means newline

In a crontab entry, % is translated to a newline. A command like date +%Y-%m-%d will break or behave oddly. Escape it as \% — or better, put the logic in a script file and keep the crontab line trivial.

4. Cron gives you a minimal environment

Cron does not source your shell profile. PATH is often just /usr/bin:/bin, so anything installed via nvm, pyenv, or a project virtualenv "works in my terminal" but fails only under cron. Fix: use absolute paths in the script and export PATH at the top of the script itself.

5. Overlaps and silence

If a job runs longer than its interval, cron happily starts a second instance — wrapped in flock to prevent it. And if stdout isn't redirected and no mail daemon exists, error output quietly disappears. Redirect to a log file and add an external health check so a dead job actually alerts you.

Gotchas like these are why I test a schedule before deploying it. When I need to decode an unfamiliar expression or build one from scratch, I use the free CodeToolbox Cron Generator — it validates each field and explains the schedule in plain language, and everything runs locally in your browser, so nothing gets uploaded.

UUIDv7 vs UUIDv4: Why Time-Sortable IDs Are Winning (and When v4 Is Still Right)

zhihu wu — Fri, 04 Sep 2026 13:03:21 +0000

If you have ever used a random UUID as a database primary key and watched writes slow down as the table grew, it was not your imagination — and the fix became an official standard back in May 2024.

The problem with random keys

A UUID v4 is 122 bits of pure randomness. Insert a few million rows and every new row lands at a random position in your B-tree index. The database keeps splitting pages and evicting cache lines, and your writes pay for it. On write-heavy tables this fragmentation is a real, measurable cost.

What UUIDv7 changes

UUIDv7 keeps the familiar 128-bit shape but replaces the first 48 bits with a Unix timestamp in milliseconds. The remaining bits are still random. Because IDs generated close together are close in value, new rows append near the end of the index instead of poking holes in the middle. B-tree locality improves, page splits drop, and you get a free bonus: rows are roughly sortable by creation time, which makes "latest first" queries and cursor pagination noticeably cheaper.

Adoption is already here

Python 3.14 added uuid.uuid7() to the standard library
The uuid npm package ships uuidv7() (v11+)
Go's google/uuid has NewV7()
Postgres has the pg_uuidv7 extension, and built-in support keeps spreading

The trade-offs you should know

UUIDv7 leaks timing information — the timestamp is right there in the ID. That is fine for database keys but wrong for security tokens, session IDs, or anything where you do not want to reveal when a record was created. Use v4 or a dedicated random token there.

Also, "time-sortable" is best-effort, not a guarantee: if one process generates IDs in a tight loop, or a machine clock rolls back, ordering can drift. For most backends that is noise; for strict event ordering you need a sequence, not a UUID.

When v4 is still the right call

If your table is read-heavy or sits under roughly ten million rows, v4 is perfectly fine — the index overhead is negligible compared with the simplicity. v4 is also what crypto.randomUUID() in browsers and Node.js produces today, and it works everywhere with zero new tooling. Do not migrate an existing happy system just to chase v7.

Try it yourself

When I need a UUID in the middle of debugging, I use a free client-side generator at CodeToolbox — everything runs in the browser, nothing is uploaded, and the page includes a quick v4 vs v7 vs ULID comparison if you want the full picture before choosing an ID strategy for your next project.

Why Your JSON Won't Parse: 6 Invisible Character Traps (and How to Fix Them)

zhihu wu — Tue, 01 Sep 2026 13:02:29 +0000

You've written JSON that looks perfectly fine. Braces match, keys are quoted, commas are in place. Yet JSON.parse() throws Unexpected token at a position that makes no sense.

Sound familiar? Here are six invisible traps that break perfectly "correct-looking" JSON — and how to spot each one.

1. Trailing commas

{"a": 1, "b": 2,} — the comma after the last item is invalid in strict JSON (it's legal in JavaScript objects, which is why it sneaks in). Editors rarely flag it. Drop the final comma and it parses.

2. Smart (curly) quotes

Copy JSON out of a word processor, email client, or chat app and the quotes come back curly: " and " instead of ". JSON only accepts the straight double quote (U+0022). Curly quotes are the #1 cause of "my JSON works in my head but not in code".

3. The hidden BOM

Files saved as UTF-8 with BOM start with an invisible byte sequence before the first {. JSON.parse() sees it as an unexpected token — the classic "error at line 1, column 1" mystery. Save as UTF-8 without BOM and it disappears.

4. Non-breaking spaces

A space that isn't a space. NBSP (U+00A0) copied from formatted text looks like whitespace to your eyes but is invalid JSON syntax when it hides between keys and colons.

5. Single quotes and unquoted keys

{'a': 1} and {a: 1} are valid JavaScript — but not JSON. RFC 8259 requires double-quoted keys and values. Hand-written config files drift into JS-object syntax all the time.

6. Duplicate keys don't throw — they silently overwrite

{"id": 1, "id": 2} parses fine, but the first value is silently discarded. Different parsers disagree on which value wins, so this causes subtle, hard-to-debug data loss.

How to debug these fast

Don't eyeball it — get a precise error location. Paste the payload into a formatter that reports the exact line and column of the first syntax error (a BOM shows up as an error at position 0, a dead giveaway). A collapsible tree view also makes duplicate keys easy to spot after a successful parse.

I use the free JSON Formatter on CodeToolbox for this — it's 100% client-side (your data never leaves the browser), reports exact error positions, and switches between format / minify / validate modes. No signup, no uploads.

The 30-second fix checklist

Replace curly quotes with straight quotes
Drop trailing commas
Save without BOM
Double-quote every key

Nine times out of ten it's one of these. Happy parsing!

How to Compress Images for the Web Without Losing Quality

zhihu wu — Mon, 31 Aug 2026 13:08:19 +0000

Images are the single biggest contributor to slow page loads — yet most developers only compress them once, at export time, and never think about it again. A 5MB photo that should weigh 150KB is the difference between a page that loads in 0.8s and one that crawls past 4s on mobile.

Here are the compression techniques that actually matter, in order of impact:

1. Resize before you compress.
If your original is 4000x3000px but your layout only needs 1200px wide, every pixel beyond that is wasted bytes. Resizing first, then compressing, routinely turns a 5MB photo into under 100KB.

2. Use WebP as your output format.
WebP is typically 25-35% smaller than JPEG at the same visual quality, and every modern browser supports it. For screenshots and UI mockups, converting PNG to WebP is often an 80-90% reduction.

3. Find the quality breakpoint, don't guess.
Start at 100% quality and slide down while previewing the result side by side. The moment you notice degradation, bump back up 5%. For most web images that lands between 70-80% — visually near-identical, 60-80% smaller.

4. Match quality to usage.
Hero images and photography portfolios deserve ~85%. Thumbnails and icons can drop to 60% where detail matters less. One setting for everything means you're either bloating thumbnails or degrading heroes.

5. Watch your Core Web Vitals.
Image weight is the #1 factor in Largest Contentful Paint (LCP). Cutting image size on your top pages can shave seconds off LCP on mobile — and since Google uses LCP as a ranking signal, it's a free SEO win alongside the speed gain.

When I need to batch-process images quickly, I use a browser-based compressor at codetoolbox.pro/tools/image-compressor — it runs entirely locally via the Canvas API, so nothing gets uploaded to a server, which matters when you're compressing screenshots of internal dashboards or customer data.

The rule of thumb: if a page's images are under 100KB total, you're probably fine. If a single image is over 500KB, it's costing you ranking and conversion. Compress once, deploy everywhere.