DEV Community: Rahib Ali

Compress JPG Images: How I Cut 60% of the Weight

Rahib Ali — Mon, 09 Nov 2026 08:28:52 +0000

Yes — you can cut most of a JPG's weight without any visible quality loss. I tested it on three real photos: a single image dropped from 606 KB to 241 KB, a second squeezed to an exact 100 KB target came out at 79 KB, and a batch of four fell from 5.60 MB to 2.47 MB.

That is 60%, 87% and 56% saved — on the same photos, with no change you can see at normal viewing size. The trick is not a secret setting. It is checking the result at full zoom instead of trusting a number on a slider.

The three tests, with real numbers

I ran the tests on ordinary photos, not special test images. Each one went through the same tool, in the browser, with nothing uploaded. The point was to see what normal settings actually do, not what a marketing page claims.

One photo, quality mode

The first photo started at 606 KB. I compressed it once, at the default quality setting, and it came out at 241 KB. That is 60% of the file gone, and at normal viewing size the two versions look the same. I only saw a difference when I zoomed in close and hunted for it.

One photo, exact target size

The second test used target-size mode. I set the target to 100 KB because that was the budget for the page. The tool returned a file of 79 KB, which is 87% smaller than the original. Hitting an exact size matters when a platform caps uploads or a page has a strict weight budget.

Four photos, bulk mode

The third test was a batch of four photos, compressed together. They started at 5.60 MB combined and finished at 2.47 MB, saving 56%. Bulk mode matters because nobody compresses one image at a time on a real site. A product page or a blog post has a dozen images, and doing them one by one is how the job never gets done.

What actually loses quality

Three things change a JPG: quality, dimensions and format. Quality is the slider most tools show you. Dimensions are the pixel width and height. Format is JPG versus PNG versus WebP. Most of the damage people blame on compression actually comes from resizing badly or saving in the wrong format.

Lowering quality removes detail your eyes cannot see at normal size. That is why a file can shrink by more than half and still look identical. The loss only shows up when you push the slider too far, or when you zoom in past 100% and look for it. At the size readers actually see, it is not there.

Google's guide to compressing images makes the same point: the goal is the smallest file that still looks right, not the lowest number on a slider.

Dimensions are the bigger lever when a photo is displayed small. A photo far wider than its display size carries far more data than the page needs. Resizing it first, then compressing, beats compressing alone every time. Check the display size before you touch the quality slider.

Format is the third choice, and it is simple. Use JPG for photos. Use PNG only when you need transparency. WebP gives smaller files than JPG at the same visible quality, and most browsers support it now. If your audience includes very old browsers, keep a JPG as the fallback. MDN's image format guide lists which browsers support WebP and which still need a fallback.

The workflow I use now

After those three tests, I settled on a short workflow. It takes a few minutes for a batch, and it works for blog images, product photos and portfolio shots alike. Here it is, in order.

Check the display size first. If the image shows smaller than its real size, resize it to the display width before anything else.
Compress once, at a middle quality setting, and check the result at 100% zoom. If it looks clean, stop there.
If you have a hard budget — say 100 KB for a page-speed target — use target-size mode and let the tool hit it exactly.
Do the whole batch at once instead of one file at a time. That is the only way a backlog of images actually gets finished.
Convert to WebP when the platform accepts it, and keep the JPG for anywhere that does not.

I ran all three tests with a free tool that can compress jpg images in the browser, with bulk mode and an exact target-size mode. Nothing is uploaded, so the photos never leave your device.

Mistakes that cost quality

The most common mistake is compressing the same file twice. Each pass throws away more detail, and the second pass has nothing good left to keep. Always compress from the original, never from an already compressed copy.

The second mistake is saving a photo as PNG because it feels safer. PNG is lossless, so it sounds better. For a photo, it usually means a file several times larger than the same image as a JPG, with no visible benefit. PNG is for graphics and transparency, not photos.

The third mistake is upscaling. If a photo is small, enlarging it will not add detail — it only makes the blur bigger, and then compression makes it worse. Use the photo at its real size, or pick a larger original.

The last mistake is skipping the zoom check. A thumbnail hides everything. Open the compressed file at 100% and look at faces, text and edges. If those are clean, the file is good. If they are not, raise the quality and try again.

What the numbers mean for a real page

A single photo at 241 KB instead of 606 KB loads faster on a slow connection, and it costs the reader less data. A batch that drops from 5.60 MB to 2.47 MB is the difference between a page that feels heavy and one that feels instant. The savings add up because a page rarely has one image.

The 79 KB result matters most for strict budgets. Some platforms cap uploads, and some pages have a weight target to meet. Target-size mode takes the guessing out of it: set the number, get a file under it, and move on. That is the feature I now reach for first when a limit is involved.

FAQ

How much can I compress a JPG without losing quality?

In my tests, between 56% and 87% came off with no visible difference at normal viewing size. The exact amount depends on the photo — busy, detailed photos compress less than simple ones — so always check the result at full zoom.

What quality setting should I use?

Start in the middle, around 80, and check the result at 100% zoom. If it looks clean, stop. If you can see damage, raise the setting and try again. There is no single right number — the photo decides.

Is 100 KB enough for a photo on the web?

Yes, for most web photos. My target-size test produced a 79 KB file that looked clean at full zoom. Large hero images shown full-screen may need more room, but for blog and product photos, 100 KB is a sensible budget.

Do I need to upload my photos to compress them?

No — not with a tool that runs in the browser. The photos I compressed never left my device, because the work happens locally. That also means there is no queue, no account and no waiting for an upload.

Does compressing a JPG twice make it smaller?

Yes, but it costs quality each time. Each pass throws away detail, and the second pass has less good data to work with. Compress once, from the original file, and keep the original safe in case you need it again.

The short version

The short version is simple: check the display size, resize first, compress once, and look at the result at full zoom. My three tests saved 60%, 87% and 56% — and none of the photos looked worse. Start with the biggest image on your slowest page. That is where the win is.

Your JSON Formatter Says "Valid" — Here's What It's Not Telling You

Rahib Ali — Mon, 09 Nov 2026 05:20:19 +0000

Last month I spent forty minutes staring at a perfectly good API response. The endpoint returned 200. The payload looked right. My app still crashed on the third record, every single time.

I pasted the response into a formatter. Big green checkmark: valid JSON. I pasted it again, slower, as if that would help. Still valid. The bug was not in the syntax at all, and that is exactly the problem with how most of us use formatters.

A "valid" verdict answers one narrow question: does this text follow the grammar of JSON? It says nothing about whether the data means what you think it means. The gap between valid and correct is where the nastiest production bugs live.

Valid is a low bar

JSON has a tiny grammar. Objects, arrays, strings, numbers, true, false, null. That is the whole language, and the formal definition fits on a single page at json.org.

A formatter that only checks grammar will happily bless a payload that loses data, misleads your code, or behaves differently in every language that touches it. The spec itself, RFC 8259, warns that object member names SHOULD be unique — and then admits that parsers disagree about what to do when they are not.

So the green checkmark is the beginning of the investigation, not the end of it. Here are the four traps I now check for every time a payload misbehaves, in the order I check them.

1. Duplicate keys silently eat your data

This is the one that bit me last month. The response contained something like this:

{
  "user_id": 4821,
  "name": "Aisha Khan",
  "plan": "starter",
  "plan": "pro"
}

Two plan keys. Perfectly valid JSON grammar. Most parsers keep the last value and throw the first one away without a word. Some keep the first. A few raise an error. Your formatter probably did not even blink.

In my case, the API had a merge bug upstream. The first plan came from the billing service, the second from a stale cache. My app read "pro", the billing page read "starter", and the customer got charged for a plan the dashboard said she did not have.

A good formatter flags duplicate keys loudly, because the JSON specification says names SHOULD be unique and duplicate names make behavior unpredictable. If yours does not, you are flying blind on the most common silent-data-loss bug in JSON.

2. Trailing commas: valid in your editor, invalid in JSON

If you write JavaScript all day, this one will get you eventually:

{
  "name": "Rahib",
  "role": "developer",
}

That trailing comma after "developer" is fine in JavaScript and Python. It is a syntax error in JSON. Strictly speaking, your formatter should reject it — and a strict one will.

The confusion runs the other way too. Some lenient tools quietly accept trailing commas, so you ship a config file that works in your editor and fails in production, where the real parser is strict. I have seen this take down a deploy: the config validated in the developer's tool, then the server's JSON parser rejected it at startup.

When a formatter accepts something, ask whether it is accepting real JSON or being polite. Politeness is not a feature here. You want the tool that fails exactly the way your production parser fails.

3. Numbers lose precision without warning

This is the trap that costs real money, and it is the one almost nobody checks:

{ "order_id": 9007199254740993 }

That number is valid JSON. It is also larger than 2^53, which means JavaScript cannot represent it exactly. Parse it with JSON.parse and you get 9007199254740992. One digit off. Your order lookup now points at a different order — or at none at all.

The same hazard hits any language with double-precision floats, which is most of them. The JSON spec places no limit on number precision, but your runtime does, and the two limits are not the same.

APIs that return large IDs as numbers are a known footgun. The safe pattern is to send IDs as strings. But you cannot fix the API from your side of the screen. What you can do is notice: a formatter that shows you the parsed value next to the raw text makes the precision loss visible before it reaches your database.

If you work with IDs, timestamps in milliseconds, or money in minor units, check what your formatter does with a 16-digit number. If it silently rounds, it is hiding exactly the bug you are trying to find.

4. Strings that look like numbers (and booleans that aren't)

JSON has exactly six value types, and the boundaries between them are where bugs breed:

{
  "is_active": "true",
  "retry_count": "3",
  "price": "19.99"
}

Every value here is a string. "true" is not the boolean true. "3" is not the number 3. In a loosely typed language, "3" + 1 gives you "31", not 4. In a strictly typed one, it gives you a type error at 2 a.m.

This usually happens when a backend serializes everything as strings — a database driver returning text columns, or a CSV import that never converted types. The JSON is valid. The types are wrong. And the failure shows up three services downstream, far from the cause.

A formatter that shows types explicitly — string vs number vs boolean, ideally with colour — turns this from a guessing game into a glance. When I am debugging a payload now, the first thing I look at is not the values. It is the types.

What a good formatter actually tells you

After a few rounds of this, my checklist for a JSON tool changed completely. When you paste a payload into an online JSON formatter, you are really asking it three questions at once: is the grammar right, are the types what I expect, and is anything being silently lost? Syntax validation is table stakes. What I actually need is a tool that:

Flags duplicate keys instead of silently accepting them.
Rejects trailing commas the way a strict parser would.
Shows parsed numbers next to raw text so precision loss is visible.
Makes types obvious at a glance, with strings, numbers, and booleans visually distinct.
Formats and minifies without ever changing the data.

That is a short list, and most tools fail at least one item on it. The one I reach for now is the free json formatter from FrostRank — it validates strictly, flags duplicate keys, and shows the parsed structure with types, which is exactly the set of checks this article is about.

The point is not which tool you use. The point is knowing what to demand from it. A formatter that only says "valid" is a spell-checker that never checks meaning.

A debugging checklist for the next bad payload

The next time a payload looks right and behaves wrong, work through these in order before you blame the API:

Check for duplicate keys. Search the raw text for repeated member names inside the same object.
Check the types. Is anything that should be a number or boolean actually a string?
Check large numbers. Any integer above 9,007,199,254,740,991 may have lost precision in transit.
Check for trailing commas and comments. Both are common in hand-written config and both are invalid JSON.
Parse it in the same language your app uses. A payload that is valid in Python and valid in JavaScript can still behave differently in each.

Most "the API is broken" bugs I have investigated turned out to be one of these five. The API was fine. The JSON was valid. And the data was wrong anyway.

That is the lesson the green checkmark never teaches: valid JSON is a promise about grammar, not about meaning. The sooner you stop treating the two as the same thing, the sooner the forty-minute mysteries become five-minute fixes.

Your barcode scans on screen but not in print? Here's the debugging order

Rahib Ali — Mon, 02 Nov 2026 05:26:53 +0000

If the barcode scans from your screen but dies the moment it's printed, the data is innocent and the print is the crime scene. Nearly every "won't scan" failure I have seen comes down to six causes: a wrong number or check digit, a cropped quiet zone, bad colors or contrast, wrong sizing, printer DPI and ink spread, or the scanner itself. Check them in that order and you will find the culprit in minutes instead of reprinting a thousand labels on a guess.

The screen test is genuinely useful, by the way. If a code decodes on a monitor, the symbology, the encoded data, and the check digit are all structurally fine — which eliminates the data half of the problem and leaves only the physical half. That split is the whole debugging strategy.

1. Start with the number, not the printer

Retail barcodes carry a built-in lie detector: the check digit. The last digit of an EAN-13, EAN-8, UPC-A, or ITF-14 is computed from the other digits with the GS1 mod-10 formula, and a scanner uses it to catch misreads. A wrong check digit is the most expensive failure on this list, because nothing looks wrong until thousands of labels are already on shelves — the code either fails outright or, worse, decodes as a different product.

The math is simple enough to check by hand. Take the first 12 digits of an EAN-13, say 590123412345: digits in odd positions count once, digits in even positions count three times.

Odd positions:   5 + 0 + 2 + 4 + 2 + 4       = 17
Even positions: (9 + 1 + 3 + 1 + 3 + 5) × 3  = 66
Total: 17 + 66 = 83 → check digit = (10 − (83 mod 10)) mod 10 = 7
Full EAN-13: 5901234123457

Type one digit wrong and the final digit changes — that is the entire point. If you are hand-rolling numbers for internal labels, validate before you print; and for anything sold in stores, remember the image is only half the job — the number inside a retail UPC or EAN has to be a GTIN licensed from GS1, or it can collide with another company's product.

2. The quiet zone is the number-one print failure

The blank margin on each side of the bars is not decoration. Scanners use the quiet zone to find where the code starts and ends, and anything printed inside it — text, borders, background graphics, a die-cut line — can kill decoding outright. GS1 New Zealand, which verifies barcodes for companies supplying retailers, reports that symbols most often fail verification because the quiet zone is too narrow or the bars are too short.

The spec is written in units of X, the width of the narrowest bar or space: an EAN-13 needs 11X on the left and 7X on the right, a UPC-A needs 9X on each side. As a rule of thumb, keep about ten times the narrow-bar width of clear space on both sides. The trap is that quiet zones die quietly in layout work — a barcode dropped into a label design, nudged against a border, or cropped to "save space" loses its margin, and the code that scanned perfectly in the generator stops scanning on the shelf. When you place a barcode, the margin is part of the barcode. The size numbers behind this are worth knowing: GS1 allows EAN-13 and UPC-A anywhere from 80% to 200% of nominal size, and the quiet zone scales with it, so a code shrunk for a small label has a proportionally smaller margin to protect.

3. Colors: contrast is physics, not taste

Most laser scanners read with red light at around 660 nm. That single fact explains the most common color mistake: red or orange bars are nearly invisible to them, because the scanner's own light reflects off red ink almost as strongly as off the white background. Inverted colors — light bars on a dark background — fail the same way, since scanners are built to find dark bars against light spaces.

The working rule is print contrast signal: PCS = (space reflectance − bar reflectance) ÷ space reflectance. Most 1D symbologies want at least 50% — black bars on a white background is the safest combination there is. Watch out for the sneaky contrast killers: glossy laminate that throws specular reflections into the scanner, yellowed thermal paper, and brand colors that look dark to your eye but reflect plenty of red light. If marketing insists on a colored barcode, test it under the actual store lighting with the actual scanner model before you commit — not on your desk, not on your phone.

4. Size: the 80–200% rule and the PNG trap

An EAN-13 at full size is 37.29 × 25.93 mm including its quiet zones, with the narrowest bar (the X-dimension) at 0.33 mm. GS1 permits 80% to 200% of that for retail — at 80% the X-dimension drops to 0.264 mm, which is the floor for reliable checkout scanning. Below that, you have built a symbol no scanner can decode reliably, no matter how clean the artwork is.

Two sizing mistakes show up constantly. The first is truncation: shortening the bar height to fit a cramped label. GS1 takes a zero-tolerance position on this — a truncated code only reads when the product crosses the beam in one particular direction, while a checkout lane scans omni-directionally. The second is the PNG trap: downloading a small raster barcode and stretching it unevenly in a design tool. Uneven scaling distorts the bar-to-space ratios the decoder depends on. For print work, generate a vector SVG and scale it proportionally, or download the PNG at the highest resolution and place it at exactly 100%.

5. Your printer is part of the barcode

Here is the failure the screen test specifically isolates. A barcode is a precision optical target, and every printer distorts it a little — the question is whether the distortion stays inside the decoder's tolerance.

Do the DPI math before you blame the artwork. A 203 dpi thermal printer lays down dots 0.125 mm across (25.4 ÷ 203). At 80% magnification your narrowest bar is 0.264 mm — barely two dots wide. Now add ink spread: on direct thermal and thermal transfer, and worse on inkjet, bars print slightly wider than specified and spaces slightly narrower. Spaces carry data too, so a narrow space that fills in is a dead code — and it looks perfectly fine to your eye, because human vision forgives what a decoder cannot. This is also why bar width reduction exists as a prepress technique: artwork is deliberately drawn with slightly narrower bars so the printed result lands on spec.

The practical rule: test on the real printer, the real stock, at the real size. The office laser that produced a beautiful proof tells you nothing about what the warehouse thermal printer will do to the same file. When volume or retail is involved, print a size ladder — the same code at 80%, 100%, and 120% — and scan each rung with the actual scanner.

6. Suspect the scanner last

If a clean, correctly sized, high-contrast code with a valid check digit still fails, interrogate the reader. Laser scanners and camera-based imagers behave differently: imagers (including phone cameras) are far more forgiving of contrast and damage, which is exactly why "scans on my phone but not at checkout" is such a common report — the phone proved the data is fine, the checkout laser is telling you the print is marginal.

Check the mundane things first: a scratched or dirty scan window, the wrong scanning distance, and — the classic — the symbology disabled in the scanner's configuration. Many handhelds ship with Code 128 subsets or less common formats switched off; the scanner will stare straight through a perfect code it has been told not to read. A phone camera app makes a fine second opinion, but remember which direction the evidence points: the forgiving reader passing and the strict reader failing means the print is borderline, not that the strict reader is broken.

The debugging order, as a checklist

Work top to bottom; stop at the first failure you find:

Verify the number. Recompute the check digit, and confirm the digits are the ones your system expects — not last month's SKU, not a truncated import.
Scan a clean reference on screen. Generate the same number fresh with a free barcode generator and decode it straight from your monitor. If the screen version scans and the printed one doesn't, the data is innocent and the print is the crime scene. (Generate it as SVG while you're there — you'll want the vector for the reprint.)
Swap the scanner. Try a second reader, ideally a different technology — phone camera versus laser. A pass on one and fail on the other isolates print quality.
Measure the quiet zone. Put a ruler on the print: roughly ten narrow-bar widths of clear space on each side, no text or borders inside it.
Check colors and contrast under real light. Dark bars, light background, no red or orange, no gloss throwing reflections at the scanner.
Print a size ladder on the real printer. Same code at 80%, 100%, and 120% on the actual stock, scanned with the actual reader.
For retail packaging, get a verification report. A scanner beep is not a quality grade.

What "good enough" actually means

Print quality for 1D barcodes is graded under ISO/IEC 15416 on an A–F scale (4.0 to 0), across parameters like symbol contrast, modulation, defects, and decodability — ten scan lines are measured, and the worst parameter sets the grade. GS1 requires retail symbols like EAN-13 and UPC-A to reach at least grade C (1.5), usually written on a verification report as 1.5/06/660: grade 1.5, measured with a 6-mil (0.15 mm) aperture under 660 nm light. A verifier is the only instrument that tells you the grade; a scanner only tells you pass or fail, today, on that reader. Most national GS1 offices offer verification services, and re-verifying once a year — or whenever you change printers, label stock, or packaging — is cheap insurance against a silent drift into unscannable.

FAQ

Why does my barcode scan on my phone but not at the store checkout?
Phone cameras are imagers: they photograph the whole code and are forgiving of marginal contrast, small sizes, and minor damage. Checkout lasers are strict — they need the full spec: intact quiet zones, strong contrast, and at least 80% magnification. A pass on the phone and a fail at the laser means the print is borderline, and the fix is in sections 2 through 5 above, not in the scanner.

Can I print barcodes on a normal office printer?
For internal labels scanned by your own devices, yes — print at 100% or larger from a vector SVG, keep dark bars on white, protect the quiet zone, and test with the scanner that will actually read them. For retail packaging or high volume, use a thermal transfer printer and get a verification report before the print run.

Do I need to buy a barcode verifier?
Only if you print retail packaging or ship to retailers who require a minimum grade. For internal inventory, asset tags, and event labels, the debugging order in this article plus a phone-camera second opinion gets you to reliable. The verifier earns its keep the moment someone else's scanner is the acceptance test.

The takeaway

"Won't scan" is never one problem — it's a short list, and the list has an order. Validate the number, isolate print from data with a screen scan, then walk the physical causes: quiet zone, contrast, size, printer. The barcode that survives that order will scan on the cheapest reader in the building, which is the only test that matters.

Further reading: BoxHero's barcode size and placement guide covers the GS1 magnification table this article summarizes, along with GS1 New Zealand's verification findings, and this print-quality guide walks through all seven ISO/IEC 15416 grading parameters.

Your JWT decodes fine — so why does the API still return 401?

Rahib Ali — Mon, 26 Oct 2026 05:24:22 +0000

You paste the token into a decoder, the header and payload look perfect, and the API still answers 401. The token is not lying to you. You are asking it the wrong question.

Decoding reverses Base64URL encoding: it needs no key and proves nothing. Verifying recomputes the signature with the signing secret or public key, then checks the claims against what the API expects. The decoder tells you what the token says; only the verifier tells you whether the API should believe it.

1. The expiry bug that looks like a valid token

JWT timestamps (exp, nbf, iat) are NumericDate values: whole seconds since 1 January 1970 UTC (RFC 7519). JavaScript's Date.now() returns milliseconds, so an issuer storing it directly as exp gets the lifetime wrong by a factor of a thousand — while the payload still looks normal.

The test is trivial: a 13-digit exp is milliseconds — divide by 1000. The same bug in nbf or iat makes a token look "not yet valid" or impossibly old.

2. Clock skew, not a broken token

A token issued by one server and verified by another lives or dies by their clocks: a verifier five minutes ahead expires a short-lived token before it arrives.

Sync both clocks with NTP and allow a 30–60 second leeway in the verifier. A token failing on only one server in a fleet is almost always a clock problem.

3. The signature is fine, but the token is for someone else

A valid signature only proves whoever holds the key signed the token. Two checks libraries do not do for you:

Audience (aud). The token must name this API; a staging token sent to production has the right signature and the wrong audience. aud can be a string or an array.

Issuer (iss). Compare it against the exact issuer URL you trust, character for character, including trailing slashes. Most such rejections are staging-versus-production mix-ups.

4. The key rotated and nobody told the verifier

The kid (key ID) header tells the verifier which key signed the token. After a rotation, tokens signed with the new key arrive while the verifier still holds the old one, or before the new key propagates — a sudden wave of "invalid signature" errors with no code change.

If the failure correlates with a deploy or rotation, check kid first, then which keys the verifier has loaded. The same symptom appears when issuer and verifier use different secrets.

5. The algorithm check you must never skip

Two algorithm mistakes are security holes, not just bugs. First, never accept alg: none: a token with no signature decodes perfectly and must be rejected outright. Second, pin the algorithm your verifier accepts — never let the token's header choose between an HMAC secret and a public key. An attacker who flips an RS256 token to HS256 can get a verifier using the public key as the HMAC secret to "verify" a token they signed themselves.

Automate the five checks

This zero-dependency script runs all five checks:

// jwt-debug.mjs — usage: node jwt-debug.mjs <token> [secret]
// Decodes a JWT, reports the checks APIs actually fail on, and
// optionally verifies an HS256 signature. No dependencies.
import { createHmac, timingSafeEqual } from 'node:crypto';

const [token, secret] = process.argv.slice(2);
if (!token) { console.error('usage: node jwt-debug.mjs <token> [secret]'); process.exit(1); }

function decodePart(part) {
  return JSON.parse(Buffer.from(part, 'base64url').toString('utf8'));
}
const parts = token.replace(/^Bearer\s+/i, '').trim().split('.');
if (parts.length !== 3) { console.error(`parts: ${parts.length} (expected 3; 5 parts means a JWE, not a JWT)`); process.exit(1); }
const [header, payload] = parts.slice(0, 2).map(decodePart);
console.log('alg:', header.alg, '| typ:', header.typ ?? '(absent)', '| kid:', header.kid ?? '(absent)');
if (header.alg === 'none') console.log('WARNING: alg=none — no signature; a correct API must reject this');
const now = Math.floor(Date.now() / 1000);
for (const claim of ['exp', 'nbf', 'iat']) {
  const v = payload[claim];
  if (v === undefined) { console.log(`${claim}: (absent)`); continue; }
  if (v > 1e12) console.log(`${claim}: ${v} — looks like MILLISECONDS, not seconds; divide by 1000`);
  else console.log(`${claim}: ${v} = ${new Date(v * 1000).toISOString()} (${v <= now && claim === 'exp' ? 'EXPIRED' : v > now && claim === 'nbf' ? 'NOT YET VALID' : 'ok'})`);
}
console.log('iss:', payload.iss ?? '(absent)', '| aud:', JSON.stringify(payload.aud ?? null), '| sub:', payload.sub ?? '(absent)');
if (secret && header.alg === 'HS256') {
  const expected = createHmac('sha256', secret).update(`${parts[0]}.${parts[1]}`).digest('base64url');
  const ok = parts[2].length === expected.length && timingSafeEqual(Buffer.from(parts[2]), Buffer.from(expected));
  console.log('HS256 signature:', ok ? 'VALID' : 'INVALID (wrong secret, rotated key, or edited token)');
}

Verified against a freshly generated HS256 token: correct secret reports VALID, a wrong secret INVALID, a millisecond exp gets flagged, and a Bearer prefix is stripped. Note it decodes only the first two parts — mapping over all three crashes trying to JSON-parse the signature, which is raw bytes, not JSON — and it uses timingSafeEqual, not ===.

Where to paste a token safely

One last rule: a live production token is a bearer credential, usable by anyone holding it until it expires, and a JWT is only encoded, not encrypted — anyone who gets it can read every claim without a key. Never put secrets in a payload; debug with a test token or an expired one.

For a quick read without a script, I use this free JWT decoder — it runs entirely in the browser, so the token never leaves my device, and converts exp, nbf, and iat to readable times with an expiry status. That client-side property is what to check in any decoder: if a tool asks for a signing secret, close the tab. Verification belongs in your API, with a maintained library, on every request.

The takeaway

"Decodes fine" is the beginning of the investigation, not the end. Convert the timestamps, check the clock, compare issuer and audience, confirm the key behind kid, and pin the algorithm — one of those five explains almost every 401 a well-formed token produces.

Redirect chains are silently slowing your site — here's how to find and fix them

Rahib Ali — Fri, 23 Oct 2026 05:18:00 +0000

You paste a URL into your browser. The page loads. Everything looks fine — but between your click and that final render, the browser may have silently hopped through two, three, or five redirects: http to https, bare domain to www, old path to new path, a trailing slash added along the way.

Browsers never show you this. They follow every hop automatically and render the destination. Redirect chains are invisible by design — and that is exactly why they quietly grow into a real problem.

Why a chain of redirects hurts

Latency. Every 301 or 302 is a full extra HTTP round trip: DNS, TLS handshake, request, response. One hop is noise. Four hops on a mobile connection is a noticeable delay before the first byte of the real page.

Crawl efficiency. Googlebot follows redirect chains, but it gives up after about 10 hops. A page that is only reachable through a long chain gets crawled less often — and Google's own documentation warns against chaining redirects where you can avoid it.

Link equity and canonicalization. A permanent move should be one clean 301 straight to the final URL. When old backlinks point at URL A, which 301s to B, which 302s to C, you are leaking both speed and signal at every step.

Search Console noise. "Page with redirect" and "Redirect error" reports are usually a chain problem, not a single-redirect problem.

See the chain: curl

The fastest honest view of a chain is in your terminal:

curl -IL https://example.com/old-page

-I fetches headers only, -L follows redirects. The output shows every hop — status code plus the Location header it points to:

HTTP/2 301
location: https://example.com/new-page

HTTP/2 302
location: https://example.com/new-page/

HTTP/2 200

That second hop is a 302 sending a permanent move to a trailing-slash variant — two separate mistakes visible in ten seconds of terminal output.

See the chain: DevTools

In Chrome or Firefox DevTools, open the Network tab, tick "Preserve log", and reload. Every request in the chain appears with its status code. This is the best option when you suspect client-side (meta refresh or JavaScript) redirects, which curl won't reveal — but it's tedious if you need to check more than a couple of URLs.

Trace chains in bulk: a tiny Node script

When a migration leaves you with hundreds of legacy URLs, clicking through each one isn't an option. This script follows a chain one hop at a time and prints it — using node:http/node:https directly, because fetch can't do this job: even with redirect: 'manual' it hands back an opaque redirect response (status 0, headers unreadable). Raw HTTP requests have no such filter:

// trace.mjs — usage: node trace.mjs https://example.com/old-page
// Zero dependencies. http.get / https.get never follow redirects,
// so each hop's real status code and Location header stay visible.
import http from 'node:http';
import https from 'node:https';

const get = (url) => new Promise((resolve, reject) => {
  const mod = url.startsWith('https:') ? https : http;
  mod.get(url, { headers: { 'User-Agent': 'redirect-tracer/1.0' } }, (res) => {
    res.resume(); // discard the body, we only need headers
    resolve({ status: res.statusCode, location: res.headers.location });
  }).on('error', reject);
});

let current = process.argv[2];

for (let hop = 1; hop <= 10; hop++) {
  const { status, location } = await get(current);
  const next = location ? new URL(location, current).href : null;

  console.log(`hop ${hop}: ${status}  ${current}${next ? `\n      → ${next}` : ''}`);

  if (!next || status < 300 || status > 399) break;
  if (hop === 10) { console.log('chain too long — stopping'); break; }
  current = next;
}

Run it against a list of URLs from your sitemap or backlink export and you'll have a full chain audit in minutes. (MDN's guide to HTTP redirections has the full reference on status-code semantics if you want the details.)

The chains I keep finding in the wild

1. The protocol + host stack. http://example.com → https://example.com → https://www.example.com. Two hops before the site even starts loading. Fix: every variant should 301 straight to the canonical URL in a single hop.

2. Trailing-slash ping-pong. /page → /page/ → /page — usually two CMS rules fighting each other. Pick one canonical form and enforce it once.

3. Migration leftovers. old-domain.com/page → new-domain.com/page → new-domain.com/renamed-page → 200. Every legacy backlink pays three hops forever. Point the old URLs directly at their final destinations.

4. The accidental 302. A permanent move shipped as a 302 or 307 because it was the framework's default. Search engines keep indexing the old URL and never fully transfer the signal. If the move is permanent, it must be a 301.

5. Redirect loops. A → B → A, and the browser gives up with ERR_TOO_MANY_REDIRECTS. Almost always two conflicting rules — a www-forcing rule plus a non-www-forcing rule, or an http→https rule fighting an https→http one.

6. Chains ending in errors. The chain "works" in the browser but lands on a 404 or 500. Always check what the final hop returns, not just that the chain resolves.

A debugging workflow that actually works

Trace the full chain — curl -IL for one-offs, the script above for bulk. When I want a quick visual answer without the terminal, I paste the URL into this free redirect chain checker, which follows every hop server-side and lists each status code and destination, with loop detection.
Count the hops. More than two to reach the final page is worth flattening.
Read the status codes. Permanent moves must be 301 — a 302/307 in the middle is a bug, not a preference.
Verify the destination. Confirm the final URL returns 200 and isn't carrying a surprise noindex.
Fix at the source. Point the original URL straight at the final destination, and update internal links, canonical tags, and sitemaps to skip the chain entirely. Redirecting to a URL that already redirects is how chains grow — one "quick fix" at a time.

Redirect chains accumulate because nothing complains about them: the browser hides them, users tolerate one extra hop, and each individual redirect looks harmless in isolation. Audit them after every migration, and spot-check your most-linked pages once in a while. The fix is almost always the same — one clean 301, straight to the destination.

Stop Hand-Writing JSON-LD: Generate Valid Schema Markup in Seconds

Rahib Ali — Sun, 04 Oct 2026 13:06:31 +0000

If you've ever hand-written JSON-LD structured data, you know the drill: one missing comma, one wrong @type, and Google silently ignores your rich results. I build SEO tools for a living, and I still don't write schema by hand anymore. Here's why — and the workflow I use instead.

Why hand-written JSON-LD breaks

JSON-LD looks simple until it isn't. The classic failure modes:

Trailing commas — valid in JS, fatal in JSON.
Wrong nesting — geo inside location vs. parallel to it for LocalBusiness.
Missing required fields — Google needs headline, author, datePublished, and image for Article. Miss one and you get no rich result, no error message, just silence.
Unescaped characters — quotes inside descriptions breaking the whole block.

The 30-second workflow

For standard schema types, a generator beats hand-writing every time. I built a free JSON-LD schema generator at FrostRank — no signup, runs entirely in your browser.

Pick the type (Article, FAQPage, Product, LocalBusiness, Organization, BreadcrumbList, Person…), fill in the fields, copy the output. It comes wrapped in <script type="application/ld+json">, ready to paste into your page.

Example output for an Organization:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Inc",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://twitter.com/example",
    "https://linkedin.com/company/example"
  ]
}

Drop it in your <head>:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Inc"
}
</script>

Always validate before you ship

Generated or not, validate everything:

Google's Rich Results Test (https://search.google.com/test/rich-results) — paste the URL or code snippet; it flags errors and confirms rich-result eligibility.
Schema Markup Validator (https://validator.schema.org/) — checks your markup against the schema.org spec itself.

If the Rich Results Test shows errors, fix the fields and regenerate — don't patch the JSON by hand and reintroduce the exact mistakes the generator saved you from.

When you SHOULD write it by hand

Generators cover the standard types. Reach for hand-written JSON-LD when:

You're combining multiple entities with @graph
You need dynamic schema injected at runtime (e.g., a product price pulled from your DB)
You're doing something exotic, like HowTo with video clips

Even then, generate the skeleton first and extend it. Starting from valid markup beats starting from a blank file.

TL;DR

Don't hand-write boilerplate schema — generate it.
Validate with Google's Rich Results Test before deploying.
Keep a generator bookmarked for the next time someone says "can you add FAQ schema to this page?"

Try the free JSON-LD schema generator — it's client-side, so nothing you paste ever leaves your tab. What's your schema workflow — generator, plugin, or hand-rolled?