DEV Community: Affan Hashmi

Before drawing a QR code, test the payload: Unicode, URLs, and double encoding

Affan Hashmi — Thu, 22 Oct 2026 00:48:39 +0000

A QR generator can draw a perfectly valid-looking image while carrying the wrong string. Two easy mistakes are turning a literal plus sign into a space and percent-encoding an already serialized URL again.

This tutorial focuses on the boundary before image generation: prepare a payload, show exactly what will be encoded, and test the transformations. The JavaScript below does not draw a QR symbol or prove that a scanner will interpret it correctly. That separation makes the tests small and the claims verifiable.

I also run qrcodeerstellenkostenlos.de, so this tutorial focuses on the payload boundary; the code below is a standalone teaching example, not the site's production implementation.

Keep three representations separate

Think of three different objects: the user's text, the serialized payload string, and the bytes supplied to an encoder. They need not have the same length or spelling.

For ordinary text, preserve the original Unicode string. A&B + 100% is text, not a query string, so its punctuation needs no URL escaping. For a URL, construct and serialize the URL first. Then hand that complete payload to a QR encoder using its documented input contract. Do not apply encodeURIComponent to the whole URL: it would also escape structural characters such as the colon and slashes.

This example uses UTF-8 for byte measurement. TextEncoder converts strings to UTF-8 bytes; string .length instead counts UTF-16 code units. Neither count is a promise of QR capacity. The example's 512-byte ceiling is an application policy, not a universal QR limit or a guarantee of scanability.

Pick an explicit contract

The text path accepts nonempty, well-formed strings, preserves spaces and line feeds, and permits tabs. It rejects other C0 controls and DEL. In particular, carriage returns are rejected instead of silently normalized. If pasted Windows line endings are expected, design that normalization as a visible, tested step before this function.

A lone UTF-16 surrogate is rejected with isWellFormed(), rather than allowing a conversion to silently change the intended content. The example requires a runtime supporting that method. It does not normalize combining marks: é and e followed by a combining acute accent retain their distinct encodings.

The URL path is intentionally narrower than the URL standard: explicit HTTPS only, no embedded username/password, no raw whitespace or backslashes, and no malformed percent escapes. These are product decisions. HTTPS syntax is not evidence that a destination is trustworthy or reachable. The function performs no network request, malware check, redirect check, or domain ownership check.

Implement the payload boundary

Save this as qr-payload.mjs. It uses built-in JavaScript APIs and needs no packages. The final result contains the payload and its measured byte length, making both available to a preview interface.

const encoder = new TextEncoder();
const MAX_BYTES = 512; // Application policy, not QR symbol capacity.

function checkedString(value) {
  if (typeof value !== "string" || !value.isWellFormed()) {
    throw new TypeError("Expected a string without lone surrogates");
  }
  return value;
}

function bounded(payload) {
  const utf8Bytes = encoder.encode(payload).length;
  if (utf8Bytes === 0 || utf8Bytes > MAX_BYTES) {
    throw new RangeError(`Expected 1 to ${MAX_BYTES} UTF-8 bytes`);
  }
  return { payload, utf8Bytes };
}

export function textPayload(raw) {
  checkedString(raw);
  // Allow tabs and LF; reject other C0 controls and DEL.
  if (/[\u0000-\u0008\u000B-\u001F\u007F]/u.test(raw)) {
    throw new TypeError("Unsupported control character");
  }
  return bounded(raw); // Preserve spaces, line feeds and Unicode exactly.
}

export function httpsPayload(raw, pairs = []) {
  checkedString(raw);
  if (!/^https:\/\//i.test(raw) || /[\s\\\u0000-\u001F\u007F]/u.test(raw) ||
      /%(?![0-9a-f]{2})/i.test(raw)) {
    throw new TypeError("Use an explicit HTTPS URL without whitespace or backslashes");
  }
  const url = new URL(raw); // No base: relative URLs must fail.
  if (url.protocol !== "https:" || !url.hostname || url.username || url.password) {
    throw new TypeError("Expected HTTPS without embedded credentials");
  }
  if (!Array.isArray(pairs)) throw new TypeError("Expected query pairs");
  for (const pair of pairs) {
    if (!Array.isArray(pair) || pair.length !== 2) {
      throw new TypeError("Each query pair needs a name and value");
    }
    const [key, value] = pair.map(checkedString);
    url.searchParams.append(key, value); // Pass unencoded strings.
  }
  return bounded(url.href); // Count after URL serialization.
}

The URL constructor parses the URL without a base, so relative references fail. It also serializes values: host spelling, default ports, and some path details can change. Always show the resulting payload to the user before generating an image. An internationalized hostname may appear in its ASCII representation; displaying that result is useful context, not a phishing detector.

Query pairs are appended as unencoded names and values. URLSearchParams handles escaping during serialization. For example, a value containing a literal + gets %2B, while a space becomes +. Supplying an already escaped value changes the meaning: the literal string %20 becomes %2520, representing those three characters rather than a space.

Appending pairs may also reserialize an existing query, so do not use this helper to modify signed URLs whose signatures depend on exact bytes. For those URLs, keep the original signed serialization and follow the signing system's contract.

Test punctuation, Unicode, and rejection paths

Save this as qr-payload.test.mjs beside the module, then run node qr-payload.test.mjs:

import assert from "node:assert/strict";
import { textPayload, httpsPayload } from "./qr-payload.mjs";

const message = "Grüße 👋\nA&B + 100%";
assert.equal(textPayload(message).payload, message);
assert.equal(textPayload(message).utf8Bytes, 23);
assert.equal(textPayload("é").utf8Bytes, 2);
assert.equal(textPayload("e\u0301").utf8Bytes, 3);
assert.equal(textPayload("é".repeat(256)).utf8Bytes, 512);
assert.throws(() => textPayload("é".repeat(257)));
assert.throws(() => textPayload("\uD800"));

const { payload } = httpsPayload("https://example.com/read", [
  ["q", "A&B + 100%"], ["topic", "café"], ["topic", "QR"]
]);
assert.equal(payload,
  "https://example.com/read?q=A%26B+%2B+100%25&topic=caf%C3%A9&topic=QR");
const parsed = new URL(payload);
assert.equal(parsed.searchParams.get("q"), "A&B + 100%");
assert.deepEqual(parsed.searchParams.getAll("topic"), ["café", "QR"]);
assert.equal(httpsPayload("https://example.com", [["q", "%20"]]).payload,
  "https://example.com/?q=%2520");
for (const bad of ["/relative", "javascript:alert(1)", "http://example.com",
  "https://u:p@example.com", "https://example.com/a b", "https://example.com/%GG"]) {
  assert.throws(() => httpsPayload(bad));
}
console.log("Payload checks passed");

The query round-trip assertions matter more than simply checking whether % appears in the result. They verify that the receiving URL parser recovers the intended values, including repeated keys. The byte-boundary tests use multibyte characters so a mistaken character-count limit cannot pass unnoticed.

Both this excerpt and a fuller local suite passed with Node v25.8.2. The fuller suite also covered empty and non-string text, both kinds of lone surrogate, preserved surrounding spaces, rejected controls, malformed query pairs, missing hosts, oversized URLs, an existing %20 path, default-port normalization, and an internationalized hostname. These are payload tests, not device or scanner tests.

Put the result into a preview, then test the encoder separately

Show the payload in a text area or via textContent, not innerHTML. Do not auto-open a submitted URL as part of validation. Keep generation errors distinct from validation errors; a payload under this demo's ceiling can still exceed a particular encoder's configured capacity.

If your encoder accepts text, confirm its Unicode encoding behavior in its documentation. If it accepts bytes, confirm how it signals the character encoding and how your target readers interpret that data. Do not assume UTF-8 byte measurement alone configures those choices. Avoid claiming universal compatibility without testing the generated symbols and intended readers.

For an end-to-end check, generate a symbol, decode it with an independently chosen decoder, and compare the recovered payload with the expected value. For printed or camera-scanned use, test the actual rendering size, contrast, quiet zone, and target devices too. No such scan tests were performed for this tutorial.

The practical boundary is simple: preserve text intentionally, serialize URL components once, and inspect the exact output before turning it into an image.

References and author context

MDN: URL constructor — URL parsing and relative references.
MDN: URLSearchParams — query serialization and plus signs.
MDN: TextEncoder — UTF-8 byte encoding.
MDN: isWellFormed — detecting lone surrogates.
WHATWG URL Standard — normative parsing and serialization algorithms.

Testing a small cost calculator: decimal inputs, units, and rounding

Affan Hashmi — Wed, 21 Oct 2026 22:04:38 +0000

A calculator can have a correct multiplication and still give misleading results. A parser might silently accept a unit suffix, a percentage might be interpreted on the wrong scale, or an intermediate value might be rounded before the final total.

This tutorial builds a small JavaScript charging-cost example with three separate responsibilities: validate text, calculate with explicit units, and format the result. The prices and consumption below are hypothetical test fixtures. This is a programming exercise, not a tariff comparison or a financial recommendation.

Write the model before the function

Use these inputs: distance in km, consumption in kWh per 100 km, a home-charging share in percent, two prices in EUR per kWh, and an energy markup in percent. The home share refers to energy, not the number of charging sessions. Each price applies to its corresponding share of billed energy.

Here, “10% energy markup” explicitly means multiplying baseline energy by 1.10. It is an additive convention. It does not mean dividing by 0.90, which would model a 10% loss measured against energy drawn from the supply. Those assumptions produce different answers; a label such as “losses” without a definition is insufficient.

The model is:

base kWh = distance km / 100 × consumption kWh/100 km
billed kWh = base kWh × (1 + markup percent / 100)
weighted EUR/kWh = home share × home price
                 + (1 − home share) × public price
cost EUR = billed kWh × weighted EUR/kWh

For 1,000 km, 18 kWh/100 km, 60% home energy, EUR 0.32/kWh at home, EUR 0.59/kWh publicly, and 10% markup, the decimal arithmetic is 180 × 1.10 × 0.428 = 84.744 EUR. The two-decimal display should be EUR 84.74.

This intentionally omits fixed fees, session fees, time-based charges, tiered rates, and location-dependent rules. If a product needs those features, extend the model and fixtures explicitly.

Define an input grammar

The parser accepts strings containing an unsigned integer, optionally followed by a decimal point and one to six fractional digits. It rejects whitespace, grouping separators, exponent notation, signs, unit suffixes, leading zeroes such as 01, and incomplete decimals such as .5 or 1.. Zero itself is valid.

That grammar is deliberately narrow. The interface should say “Use a decimal point; no thousands separators” and show an example such as 0.32. Do not guess whether 1,000 means one thousand or one with three decimal places. A localized interface needs a separate, explicitly specified parsing policy; changing the output locale does not implement one.

Validation has two stages. The regular expression checks the whole text; conversion then produces a number. Number.isFinite rejects non-finite results, including overflow from an enormous digit string. Field bounds reject values outside this example's operating range. These bounds are illustrative product decisions, not universal engineering limits.

Keep calculation separate from formatting

Save this as calculator.mjs. It uses no packages. Pass the field strings directly to estimate; missing fields fail validation rather than becoming zero.

export function decimal(text, name, max) {
  if (typeof text !== "string" ||
      !/^(?:0|[1-9][0-9]*)(?:\.[0-9]{1,6})?$/.test(text)) {
    throw new TypeError(`${name}: use digits and an optional decimal point (up to 6 places)`);
  }
  const value = Number(text);
  if (!Number.isFinite(value) || value < 0 || value > max) {
    throw new RangeError(`${name}: expected 0 to ${max}`);
  }
  return value;
}

export function estimate(input) {
  const distanceKm = decimal(input.distanceKm, "distanceKm", 1_000_000);
  const kWhPer100Km = decimal(input.kWhPer100Km, "kWhPer100Km", 1_000);
  const homePercent = decimal(input.homePercent, "homePercent", 100);
  const homeEurPerKWh = decimal(input.homeEurPerKWh, "homeEurPerKWh", 100);
  const publicEurPerKWh = decimal(input.publicEurPerKWh, "publicEurPerKWh", 100);
  const markupPercent = decimal(input.markupPercent, "markupPercent", 100);

  const baseKWh = distanceKm / 100 * kWhPer100Km;
  const billedKWh = baseKWh * (1 + markupPercent / 100);
  const homeShare = homePercent / 100;
  const weightedEurPerKWh = homeShare * homeEurPerKWh +
    (1 - homeShare) * publicEurPerKWh;
  const costEur = billedKWh * weightedEurPerKWh;
  return { baseKWh, billedKWh, weightedEurPerKWh, costEur };
}

export const eur = new Intl.NumberFormat("en-IE", {
  style: "currency", currency: "EUR",
  minimumFractionDigits: 2, maximumFractionDigits: 2
});

The upper bounds are 1,000,000 km, 1,000 kWh/100 km, EUR 100/kWh, and 100% markup; home share is restricted to 0–100%. They keep this example's intermediates finite. A real application should choose limits from its own requirements and explain rejected values near the fields.

For a browser form, associate visible labels and unit hints with each input, use inputmode="decimal" where appropriate, and show validation messages accessibly. A keyboard hint is not validation. If a server uses the submitted inputs, enforce the same contract there too.

Test the assumptions and the boundaries

Save the following as calculator.test.mjs beside the module, then run node calculator.test.mjs. It uses Node's built-in assertion module. The tolerance is an absolute 1e-9 EUR for these small fixtures; it is not a general comparison policy for every numerical application.

import assert from "node:assert/strict";
import { decimal, estimate, eur } from "./calculator.mjs";

const input = {
  distanceKm: "1000", kWhPer100Km: "18", homePercent: "60",
  homeEurPerKWh: "0.32", publicEurPerKWh: "0.59", markupPercent: "10"
};
const close = (actual, expected) =>
  assert.ok(Math.abs(actual - expected) < 1e-9);
const result = estimate(input);
close(result.baseKWh, 180);
close(result.billedKWh, 198);
close(result.costEur, 84.744);
assert.equal(eur.format(result.costEur), "€84.74");
for (const [homePercent, expected] of [["0", 116.82], ["100", 63.36]]) {
  close(estimate({ ...input, homePercent }).costEur, expected);
}
close(estimate({ ...input, distanceKm: "0" }).costEur, 0);
close(estimate({ ...input, markupPercent: "0" }).costEur, 77.04);
for (const bad of ["", "18kWh", "0,32", "1,000", "Infinity", "-1", "1e3"]) {
  assert.throws(() => decimal(bad, "sample", 100));
}
assert.throws(() => estimate({ ...input, homePercent: "101" }));
console.log("All checks passed", result.costEur, eur.format(result.costEur));

The endpoint cases are useful because they remove one price from the calculation: 0% home gives EUR 116.82, while 100% gives EUR 63.36. Zero distance should give zero energy cost. Zero markup should recover the baseline calculation, EUR 77.04. These checks expose reversed shares and percentage-scale errors more directly than many similar middle-of-range examples.

Expand the suite with zero consumption, both prices zero, each field's upper boundary, a value just above each boundary, omitted fields, excessive fractional digits, and numeric values passed where strings are required. Test malformed text independently from out-of-range numbers so failures identify the contract that broke.

The accompanying example was run with Node v25.8.2. Its fuller local suite also checked those cases, including 24 malformed/type inputs, six upper-bound violations, and all six missing fields. These checks passed. They verify this implementation against the stated model; they do not validate real tariffs or driving consumption.

Understand what the displayed cents mean

JavaScript Number uses IEEE 754 binary floating-point arithmetic. Many decimal fractions are approximations. In the tested run, the raw result was 84.74400000000001, not an exact decimal 84.744; the energy intermediate was 198.00000000000003.

The formatter produces €84.74 without changing the returned numeric value. Do not feed that formatted string back into the calculation or round the weighted price to cents before multiplying. Display rounding cannot recover precision already lost in intermediate rounding.

This approach suits a clearly labeled estimate. It is not a money ledger. Billing or accounting software needs an explicit precision model and rounding rules at the required business boundaries. Integer minor units alone do not settle fractional energy rates or allocation rules. Avoid treating an added Number.EPSILON as a universal currency fix.

The useful design habit is to make the contract visible: input syntax, units, percentage meaning, bounds, and rounding stage. Then the tests can check a named decision instead of merely repeating arithmetic.

References

MDN: Number — numeric representation and conversion.
MDN: Number.isFinite — finite-number checks without coercion.
MDN: Intl.NumberFormat — locale-aware display formatting.

I also run EAutoKompass; the code here is a standalone teaching example rather than the site's production code.