DEV Community: Mubashir Ali

Why Your JSON Parse Failed, and Why Decoding a JWT Isn't Verifying It

Mubashir Ali — Thu, 29 Oct 2026 11:31:39 +0000

Why Your JSON Parse Failed, and Why Decoding a JWT Isn't Verifying It
The API returned 200. Your frontend is dead anyway.
SyntaxError: Unexpected token } in JSON at position 118
Somewhere between the server and your parser there is a payload that looks like JSON, reads like JSON, and is not JSON. Here is how to find the break quickly, plus the JWT version of the same trap, because the two failures travel together in real debugging sessions.
Read the error as coordinates, not as an insult
A JSON parse error gives you a position. Use it. In Python the message is wordier and even more helpful:
import json

json.loads(payload)

json.decoder.JSONDecodeError: Expecting property name

enclosed in double quotes: line 4 column 3 (char 61)

Line 4, column 3 is where the parser gave up, and the actual mistake usually sits a character or two before it. Open the payload, go to that line, and look left. Nine times out of ten you will see one of the usual suspects.
The usual suspects, all in one payload
{
'user': 'ada',
"roles": ["dev", "admin",],
"score": undefined,
}
That short block contains three separate failures:
Single quotes. JSON strings need double quotes. 'ada' is JavaScript, not JSON.
A trailing comma. "admin",] and the comma after undefined are both legal in modern JavaScript objects. In JSON they end the parse.
An unquoted literal. undefined and NaN do not exist in JSON. Use null, or leave the key out.
Two more worth memorising because they pass a quick visual scan: comments (// looks fine) aren't allowed, and neither are unquoted keys. If you generated the payload by hand, or a template engine did, check those first.
Pasting the payload into a formatter is the fastest way to see the break in context. I use the JSON Formatter on a site I maintain, because it shows a tree view next to the raw text and the error position stops being abstract. Any formatter you trust does the same job. The point is seeing the structure, not squinting at a 400-character one-line string from a log file.
Now the token that "looks fine"
A JWT is three base64url segments joined by dots:
header.payload.signature
Decoding the first two segments is trivial, and you should know how to do it locally:
const decodePart = (part) =>
JSON.parse(atob(part.replace(/-/g, "+").replace(/_/g, "/")));

const [header, payload] = token.split(".").slice(0, 2).map(decodePart);
Watch the padding, by the way. Base64url drops the trailing = characters, and strict decoders in some environments will reject a segment whose length is not padded back to a multiple of 4. Browser atob usually copes. Your mileage will vary, quietly, at the worst moment.
Reading the payload answers the questions that cause most 401s:
exp is in seconds, not milliseconds. Compare it against Date.now() / 1000. Half the "token randomly rejected" bugs I have chased in discussions and issues came down to a unit mismatch or a server clock a few minutes adrift.
iss and aud must match what the API expects, exactly. A token minted for one environment fails against another with no useful error message.
alg in the header tells you what the issuer claims to have signed with. If it says none on a token guarding anything real, stop and go and read your auth library's defaults.
Decoding is not verifying. Say it twice.
Everything above reads the token. None of it proves the token is genuine, because the payload is not encrypted. Anyone holding the string can read every claim in it, and anyone can rewrite those claims, set "role": "admin", and produce a perfectly well-formed token. Only the signature check, done by your server with the issuer's key, separates a real token from a typed one.
Two habits follow from that:
Never put anything secret in a payload. Treat every claim as printed on a postcard.
Never paste a live production token into a random website. For a throwaway dev token, a browser decoder like this JWT Decoder saves a minute. For anything real, decode locally with the snippet above. A token is a credential, and credentials do not go into strangers' text boxes. That includes mine.
Regex: fine for shape, useless for parsing
You'll be tempted to validate payloads with regex. Resist, mostly. JSON needs a parser, and a regex can't give you one. What regex can do is check the shape of a token while you scan logs:
^[A-Za-z0-9_-]+.[A-Za-z0-9_-]+.[A-Za-z0-9_-]+$
Three pitfalls sit inside even this simple pattern:
The dots must be escaped. An unescaped . matches any character, so abcXdefYghi sails through a sloppy version of this test.
Anchors matter. Without ^ and $, the pattern matches a valid-looking substring inside a longer piece of junk and reports success.
Greedy quantifiers hide sins. A .* in the middle will swallow the separators you were trying to count.
I test patterns against a handful of deliberately wrong strings, not just the one good string, in a Regex Tester (same site, disclosure below). A pattern that only ever sees valid input has told you nothing.
The two-minute workflow, in order
Read the parse error's line and column. Look left of that point.
Check for trailing commas, single quotes and an undefined that should be null.
Format the payload and read it as a tree, not a string.
For a 401, decode the token locally and compare exp, iss and aud against what the API expects.
Verify the signature on the server before you trust a single claim.
Do it in that order and most "the API is broken" reports resolve into one tired character in the wrong place. It is rarely the API. It is almost never the API.
Disclosure: I build Xplosole, the site behind the three tools linked above. The tutorial works without them — every step has a local-code route, which for real tokens is the route you should take.

URLs verified live — 24 Oct 2026 (all HTTP 200)
https://www.xplosole.com/tools/pdf/pdf-merger
https://www.xplosole.com/tools/image/background-remover
https://www.xplosole.com/tools/image/image-compressor
https://www.xplosole.com/tools/finance/invoice-generator
https://www.xplosole.com/tools/text/json-formatter
https://www.xplosole.com/tools/developer/regex-tester

"Compressing a PDF to a Target Size in the Browser", a developer write-up with code from the site's own compressor

Mubashir Ali — Tue, 06 Oct 2026 16:05:57 +0000

an exact target file size (e.g., < 2 MB) using WebAssembly, PDF.js, and Canvas?In this write-up, we’ll explore how browser-based PDF compression works, why reaching a specific target size requires a dynamic binary search loop, and how to build a client-side compressor step by step.Target Keywords & SEO StrategyPrimary Keywords: In-browser PDF compression, compress PDF client-side, PDF.js compress PDF to target size, pdf-lib browser compression.Secondary Keywords: Client-side document processing, JavaScript canvas PDF compression, web worker PDF processing.The Architecture: How In-Browser PDF Compression WorksA PDF is essentially a container. While it can contain vector graphics and text streams, scanned documents and image-heavy PDFs make up over 80% of oversized files. The most effective way to shrink a PDF in the browser without altering text layout is to re-encode its raster images at lower resolutions and higher JPEG compression ratios.Here is the high-level workflow:[ Input PDF File ]
│
▼
[ PDF.js / pdf-lib ] ──► Extract & Render Pages to HTML5 Canvas
│
▼
[ Dynamic Compression Loop (Binary Search) ]
├── Adjust Image Quality (0.1 – 1.0)
├── Adjust Scale / DPI (e.g., 1.0x, 0.75x)
└── Render Page Frame to JPEG Blob
│
▼
[ Assemble New PDF with pdf-lib ]
│
▼
[ Final Size <= Target Size? ] ──YES──► [ Output Compressed PDF ]
│
NO (Refine Quality / Downscale)
Step 1: Loading PDF Pages onto HTML5 CanvasWe use PDF.js to render each PDF page into a hidden standard element. From the canvas, we can export JPEG image buffers with variable quality levels.JavaScriptimport * as pdfjsLib from 'pdfjs-dist';

// Set up worker
pdfjsLib.GlobalWorkerOptions.workerSrc = '//mozilla.github.io/pdf.js/build/pdf.worker.mjs';

async function renderPageToCanvas(pdfDoc, pageNum, scale = 1.0) {
const page = await pdfDoc.getPage(pageNum);
const viewport = page.getViewport({ scale });

const canvas = document.createElement('canvas');
const context = canvas.getContext('2d');
canvas.height = viewport.height;
canvas.width = viewport.width;

await page.render({
canvasContext: context,
viewport: viewport,
}).promise;

return canvas;
}
Step 2: The Target-Size Search AlgorithmStandard compressors ask the user for a static setting (e.g., "Low", "Medium", "High"). But if a user specifically requests "Make this PDF under 2 MB", a static setting might produce 2.4 MB (too big) or 400 KB (unnecessarily degraded quality).To hit a target size accurately, we implement a Binary Search Algorithm over the image quality range [0.1, 0.95]:JavaScriptimport { PDFDocument } from 'pdf-lib';

async function compressPDFToTargetSize(fileBuffer, targetSizeBytes, maxPasses = 5) {
const pdfDoc = await pdfjsLib.getDocument({ data: fileBuffer }).promise;
const pageCount = pdfDoc.numPages;

let minQuality = 0.1;
let maxQuality = 0.95;
let bestBuffer = null;
let scale = 1.0;

for (let pass = 0; pass < maxPasses; pass++) {
const currentQuality = (minQuality + maxQuality) / 2;
const newPdf = await PDFDocument.create();

for (let i = 1; i <= pageCount; i++) {
  const canvas = await renderPageToCanvas(pdfDoc, i, scale);

  // Export canvas frame as JPEG image with target quality factor
  const jpegDataUrl = canvas.toDataURL('image/jpeg', currentQuality);
  const jpegImage = await newPdf.embedJpg(jpegDataUrl);

  const page = newPdf.addPage([canvas.width, canvas.height]);
  page.drawImage(jpegImage, {
    x: 0,
    y: 0,
    width: canvas.width,
    height: canvas.height,
  });
}

const outputPdfBytes = await newPdf.save();
const currentSize = outputPdfBytes.byteLength;

console.log(`Pass ${pass + 1}: Quality=${currentQuality.toFixed(2)}, Size=${(currentSize / 1024 / 1024).toFixed(2)} MB`);

if (currentSize <= targetSizeBytes) {
  bestBuffer = outputPdfBytes;
  // Try to get higher visual quality if room allows
  minQuality = currentQuality; 
} else {
  // Too large, decrease quality threshold
  maxQuality = currentQuality;
}

// Edge case: If quality is already low and file is still too big, downscale dimensions
if (maxQuality < 0.25 && currentSize > targetSizeBytes) {
  scale *= 0.8;
  minQuality = 0.1;
  maxQuality = 0.8;
}

}

return bestBuffer || (await newPdf.save());
}
Key Performance & Memory OptimizationsProcessing high-resolution PDFs entirely in the browser main thread can lead to UI freezes or out-of-memory errors on mobile devices. Here are key performance strategies:1. Offload Heavy Work to Web WorkersRun PDF rendering and page embedding inside a Web Worker or offscreen canvas context. This keeps the UI thread responsive and smooth at 60 FPS.2. Clean Up DOM ObjectsAlways release canvas objects and image memory explicitly to prevent memory leaks during multi-pass compression loops:JavaScriptcanvas.width = 0;
canvas.height = 0;

Handle Hybrid PDFs GracefullyIf a PDF contains crisp vector text mixed with photos, re-rasterizing every page turns sharp text into bitmaps. A hybrid approach checks stream objects:For image streams: Downsample images directly using pdf-lib.For scanned pages: Render full page frames to .Benefits of Client-Side PDF CompressionFeatureServer-Side ProcessingClient-Side (Browser) ProcessingPrivacy & SecurityFiles uploaded to remote servers100% private; zero bytes leave deviceInfrastructure CostsHigh CPU & bandwidth expenses$0 server footprintSpeedNetwork transfer bottleneckInstant local processing speedOffline SupportRequires continuous internetWorks offline via Progressive Web App (PWA)ConclusionBy combining PDF.js, pdf-lib, and an adaptive binary search algorithm, web applications can achieve exact-target PDF compression completely on the client side. This pattern delivers fast, privacy-preserving performance while reducing backend costs to zero.

Don't Get Math Wrong: Building a Lightweight Multi-Tier Discount Engine

Mubashir Ali — Fri, 02 Oct 2026 15:12:52 +0000

How I Solved the "Stacked Discount" Logic Problem in Next.js

Retailers love running promotions like "20% OFF — Plus an Extra 10% at Checkout!"

To most consumers, mental math translates this into $20\% + 10\% = 30\%$ off. But computationally and financially, compound (or stacked) discounts don't work linearly. Each consecutive percentage reduction applies to the remainder of the previous price, not the base original price.

When building a utility tool suite for xplosole, I needed to design a flexible engine that could handle single markdowns, reverse percentages, and arbitrary multi-tier stacked discounts cleanly in the browser.

Here is how the logic works and how to implement it efficiently.