DEV Community: Mohammed Awny

Why {"id":1}{"id":2} fails JSON.parse() — and when to wrap it in an array

Mohammed Awny — Sat, 26 Sep 2026 16:16:08 +0000

If you copy two JSON objects from a log, an AI response, or two API outputs, you may end up with this:

{"id":1}{"id":2}

Each object is valid on its own. Together they are not one JSON document. JSON.parse() reads the first object, then encounters more content where it expects the input to end. In recent V8 versions you may see “Unexpected non-whitespace character after JSON.” In Python, json.loads() often reports “Extra data.”

The right fix depends on what the two objects represent.

One collection? Make an array

If these are two entries in a single document, wrap them in brackets and separate them with a comma:

[
  {"id":1},
  {"id":2}
]

Now JSON.parse() returns an array of two entries. This is what you want for a JSON file or a single API response containing a list. Do not blindly insert a comma between objects without the array: {"id":1},{"id":2} is still not a valid single JSON document.

Separate events? Keep one record per line

Some logs use NDJSON (newline-delimited JSON): each line is an independent JSON value. That format is useful for event streams, but the whole file is not a single JSON document:

{"id":1}
{"id":2}

Parse lines separately when your producer really guarantees one complete JSON value per line:

const records = raw
  .split(/\r?\n/)
  .filter(line => line.trim())
  .map(line => JSON.parse(line));

That snippet is not suitable for pretty-printed, multiline objects or incomplete stream chunks. Use a proper streaming parser for those. Converting an event stream into one array also changes its meaning and forces you to hold the collection in memory.

Before applying an automatic repair

Check that both objects are complete and that you intend a collection. If the second object ends halfway through a string, the missing data cannot be inferred. And if the response starts with <html>, you likely fetched an error page rather than JSON; inspect the HTTP response instead of changing its syntax.

I maintain QuickTiny. Its free JSON formatter and validator detected the exact {"id":1}{"id":2} example above and offered to wrap the two complete objects in an array. I checked the result in the browser: [{"id":1},{"id":2}] is valid. Use it only when an array matches your data model; it does not repair truncated data.

Have you seen concatenated objects in an API response, an event log, or an AI output? The origin usually tells you which representation is correct.

Why Shopify Rejects a Small Product Image: 25 MP vs 20 MB

Mohammed Awny — Wed, 23 Sep 2026 16:34:53 +0000

A product image can fail a Shopify upload even when its file is only a few megabytes. The reason: file size and pixel count are different limits. Compressing bytes will not fix an image that has too many pixels.

I ran a small upload test with product images in a live Shopify store and checked the result against Shopify's product-media documentation. The documentation says product and collection images can have up to 25 megapixels (its example is 5000 × 5000 pixels) and must be smaller than 20 MB. These figures are for product and collection media; other upload contexts can have different requirements.

What the upload test showed

Image	Pixel count	File size	Result
5000 × 5000	25.00 MP	Under 20 MB	Accepted
5200 × 5200	27.04 MP	Under 20 MB	Rejected for megapixels
3200 × 3200	10.24 MP	29.9 MB	Rejected for file size

The 5200 × 5200 image failed with a megapixel error. The 3200 × 3200 image passed the pixel-count test but failed the file-size test. In each case, changing the wrong property would leave the actual problem in place.

I then resized the rejected 5200 × 5200 image to 4898 × 4898 (23.99 MP) and uploaded that output; Shopify accepted it. Separately, compressing the rejected 29.9 MB image to 8.81 MB without changing its 3200 × 3200 dimensions produced an accepted upload. The full test table and method include the exact rejection messages and downloadable data.

A quick preflight in the browser

Before uploading, inspect both properties:

const megapixels = (width * height) / 1_000_000;
const megabytes = file.size / 1_000_000;

console.log({ megapixels, megabytes });

If pixel count is over the limit, resize dimensions, preserving aspect ratio. If bytes are over the limit, compress or change the export format. If both are over, do both. Leave some margin below the limit rather than aiming for the precise boundary. This simple preflight only covers those two checks; a valid file can still run into format or other upload problems.

For a non-square image, multiply its width and height: 6000 × 4000 is 24 MP. It passed in our product uploader test, even though one side exceeds the 5000-pixel square example. That is why total pixels are more useful than memorizing one width or height.

If you want to test one product photo without writing code, the free Shopify image checker reports which limit it hits and can fix the image locally in your browser. It is an independent tool, not a Shopify app or Shopify-endorsed product; no account or upload to QuickTiny's server is required for the single-image checker.

Scope: This was an empirical test on one store's product-image uploader in September 2026. Shopify can change its rules, so check its current documentation when you rely on a limit for production. Have you seen an image rejected for a reason other than bytes or megapixels? I'd be interested in the exact error message.

Why “Unexpected token '<'” is usually an HTTP problem

Mohammed Awny — Wed, 23 Sep 2026 13:31:11 +0000

If response.json() throws Unexpected token '<', inspect the response before changing your JSON parser. The first character is often the start of <!doctype html>: your request received an HTML page.

This can happen when an API route returns a 404 page, an authentication flow redirects to a login page, or a frontend fallback serves index.html for an unknown path. A 200 status alone does not prove the response is JSON.

Read the response once

async function getJson(url) {
  const response = await fetch(url);
  const contentType = response.headers.get("content-type") ?? "";
  const raw = await response.text();

  if (!response.ok || !contentType.toLowerCase().includes("json")) {
    throw new Error(
      `Expected JSON; got HTTP ${response.status}, ${contentType || "unknown content type"} at ${response.url}. Body: ${raw.slice(0, 160)}`
    );
  }

  try {
    return JSON.parse(raw);
  } catch (error) {
    throw new Error(
      `Invalid JSON at ${response.url}: ${error.message}`,
      { cause: error }
    );
  }
}

const products = await getJson("/api/products");

Read the body with text() once. Calling response.json() afterward on the same response fails because the body has already been consumed. Parsing the captured string with JSON.parse(raw) avoids that trap.

What to check next

Look at HTTP status, final URL, and Content-Type in the Network tab. A login redirect can change the final URL; a missing route can return an HTML error page.
If the response is HTML, fix the endpoint, authentication, routing, or server response. Editing a formatter cannot turn an HTML page into the intended API data.
If it really is JSON but parsing fails, inspect the returned text around the position in the error. Common mistakes include trailing commas, single-quoted strings, and an unquoted property name. Those are not valid JSON even though they can look like JavaScript object literals.
Do not automatically “repair” incomplete or truncated data. Retry the request or fix the producer; guessing the missing portion can silently change the meaning.

For a quick, browser-based inspection of an actual JSON payload, QuickTiny's JSON Formatter shows parse errors and handles some unambiguous formatting mistakes. I maintain QuickTiny. Check sensitive payloads against your own data-handling policy before using any tool.

The key diagnostic step is simple: verify what the server sent before assuming the parser is broken.

How I Detect JSON, Base64, URLs, and Timestamps Without AI

Mohammed Awny — Tue, 22 Sep 2026 16:45:23 +0000

Format detection sounds simple until the inputs overlap.

A numeric string might be a Unix timestamp, an identifier, or valid-looking Base64. A normal word can use only Base64 characters. JSON often arrives wrapped in Markdown fences or surrounded by an LLM explanation.

For QuickTiny Smart Actions, I wanted the browser to suggest the right tool without uploading the pasted value or calling an AI model.

The detection order

The order is intentional:

Valid JSON objects or arrays
Fenced, wrapped, or conservatively repairable JSON
Plausible Unix timestamps in seconds or milliseconds
URL-encoded text with valid percent escapes
Base64 with additional plausibility checks
Multiline or list-like text
Plain text as the fallback

Stronger signals run before weaker ones.

JSON first

Strict parsing is the highest-confidence check:

function isJsonObjectOrArray(value) {
  try {
    const parsed = JSON.parse(value);
    return parsed !== null && typeof parsed === "object";
  } catch {
    return false;
  }
}

The repair path is deliberately limited. It can remove Markdown fences, extract a complete object or array from surrounding text, remove trailing commas, and quote simple keys.

It should not invent missing values or guess a schema.

Timestamps before Base64

A loose Base64 regex will match many numeric strings. I exclude pure numbers from Base64 detection and test timestamps by magnitude first.

The value must also fall within a plausible date range. That prevents every short integer from being labeled as a date.

Base64 needs more than a regex

Character-set matching is only the beginning. The detector also checks:

Minimum length
Padding shape
Impossible remainder lengths
Whether decoding succeeds
The proportion of printable decoded bytes
Whether the input is only numeric

Even then, Base64 is a suggestion—not a certainty.

URL-encoded values

The input must contain valid percent-encoded byte sequences, and decoding must succeed. A normal sentence containing a percent sign should not be routed to a URL decoder.

Lists and plain text

Multiline input is useful for cleaning, sorting, and duplicate removal. Everything else falls back to word counting, text cleanup, and case conversion.

Privacy boundary

All detection runs in the browser. QuickTiny records only categorical events such as “detected Base64,” never the pasted value.

This is why deterministic heuristics were a better fit than an AI API for this feature: they are fast, explainable, local, and cheap.

The main lesson

The goal is not to classify every string confidently. The goal is to provide a useful suggestion while keeping the user in control.

Try the live detector:

https://quicktinyv2.vercel.app/

Full methodology:

https://quicktinyv2.vercel.app/how-smart-actions-detects-pasted-content

If you find a non-sensitive value that routes to the wrong tool, I’d genuinely like to see it.

I Built a Browser Tool That Detects What You Paste

Mohammed Awny — Tue, 22 Sep 2026 12:08:50 +0000

I kept switching between tiny web tools just to handle everyday developer tasks:

Formatting JSON
Decoding Base64
Cleaning URLs
Converting Unix timestamps
Removing duplicate lines
Transforming text

So I built QuickTiny.

The main feature is Smart Actions: paste almost anything, and QuickTiny tries to recognize the content and suggest the right tool automatically.

For example:

Paste JSON → format and validate it
Paste Base64 → decode it
Paste a Unix timestamp → convert it
Paste URL-encoded text → decode it
Paste a list → clean, sort, or remove duplicates

Everything runs locally in the browser. There is no signup, and the pasted content is not uploaded.

QuickTiny currently includes 13 small browser tools. I’m trying to keep the interface fast and focused instead of turning it into a crowded toolbox.

Try it: https://quicktinyv2.vercel.app

Watch the short Smart Actions demo: https://quicktinyv2.vercel.app/quicktiny-smart-actions-demo.mp4

I’d appreciate honest feedback—especially examples that Smart Actions detects incorrectly or tools you repeatedly need during development.