DEV Community: FUG

QR Error Correction, Center Logos, and the Difference Between Static and Redirect Codes

FUG — Thu, 08 Oct 2026 20:57:50 +0000

As of October 8, 2026

What a QR code can recover

When we add a logo to a QR code, we are deliberately covering part of the symbol. That sounds like an error, because it is one. The reason a phone can sometimes read the result is that QR codes encode redundant information using Reed–Solomon error correction. We build free web tools, and this is one of the places where understanding a small technical detail makes a large practical difference.

QR codes offer four commonly named error correction levels: L, M, Q, and H. Higher correction adds redundancy, but it also takes capacity. Given the same content, a higher level may require a denser symbol. The percentages typically associated with each level describe approximate recoverable damage to codewords, not a guarantee that a logo covering that percentage of the visible square is safe.

Level	Approximate recovery	Typical decision
L	7%	Clean, unobstructed environments
M	15%	General-purpose codes
Q	25%	Modest decoration with testing
H	30%	More margin for a centered logo

A central logo is particularly unforgiving when it overlaps functional patterns or when the code is already dense. The three large position markers, their surrounding quiet regions, and other structural elements are essential. Error correction cannot repair every arbitrary shape of damage.

A minimal implementation

The familiar open-source JavaScript qrcode package allows a level to be selected explicitly. For a simple test page, an example looks like this:

import QRCode from "qrcode";

const destination = "https://example.org/info";
const pngDataUrl = await QRCode.toDataURL(destination, {
  errorCorrectionLevel: "H",
  margin: 4,
  width: 640,
});

document.querySelector("#preview").src = pngDataUrl;

This example generates a normal QR image. It does not add a logo or prove that one is safe. If your UI overlays a logo afterward, you need a separate scan test of the finished composite. Keep the destination short when possible, because longer payloads can produce more modules. Test with multiple phones, camera distances, and lighting conditions, including the worst case you expect on paper.

The margin option matters too. A QR code needs a quiet zone, usually at least four modules of uninterrupted background around the symbol. Cropping tightly for visual balance can break recognition even when the central data remains untouched.

Static payloads versus redirect services

A static QR code contains the destination itself, such as a URL, Wi-Fi configuration, or contact fields. A redirect-based dynamic service commonly puts its own short URL in the symbol and forwards scans to the destination configured on its server. That approach can make the destination editable, but it also adds a service dependency.

People often say a static QR code never expires. More precisely, the encoded data does not carry a service-imposed expiration date. The destination website can still shut down, a domain can lapse, a Wi-Fi password can change, or an event can end. The pattern on the page stays the same, but what it points to may stop working.

For a long-lived poster, we prefer an address the publisher controls. We also suggest printing the human-readable URL nearby. A scan failure should not make the information inaccessible.

PNG or SVG for production?

PNG is a raster image. Its quality depends on the exported pixel dimensions relative to the size at which it is printed. A sufficiently large PNG can work perfectly well on a small card, but enlarging a small export introduces blurry edges. SVG uses vectors, so a designer can scale it to a larger sign without interpolation blur.

Neither format rescues poor contrast, an undersized quiet zone, or an excessively ornate mark. Dark modules on a light background remain the safest starting point. Color combinations should be inspected in grayscale as well as on screen. A glossy surface or reflected light can undermine an apparently strong design.

When handing files to a print shop, communicate the final physical dimensions. Exporting a huge bitmap without knowing the target size is less useful than confirming the final module size and printing a proof.

Our review routine before putting a QR code in public

We first generate an undecorated version and scan it. Then we raise the error correction level if a logo is necessary, keep the logo compact, and scan the resulting composition. We check the printed proof rather than trusting a monitor preview. Finally, we verify the exact payload, including capitalization and punctuation in the destination URL.

We treat QR codes as interfaces, not decoration. Their job is to transfer a small piece of information reliably. A beautiful code that nobody can scan fails that job.

FAQ

Does level H guarantee that a large logo will scan?

No. H adds more recovery capacity, but location, density, contrast, printing, and decoder behavior still matter. The finished code must be tested.

Does a static QR code need an account or monthly renewal?

The encoded pattern needs neither. Whether the resource at the destination remains available is a separate question.

Which download should we use for a poster?

SVG is convenient for scaling in a print layout. A large, sharply rendered PNG may also work when the final dimensions are known.

We made a free browser-based QR generator with nine payload types, options for logos, colors, and shapes, and PNG or SVG downloads. Codes are generated in the browser without a redirect layer; it also includes a separate group check-in room feature. Try the free QR generator.

Check a Password Against a Breach List Without Sending the Password

FUG — Wed, 07 Oct 2026 20:11:23 +0000

As of October 8, 2026

A password check can query a breach list without putting the password in an HTTP request. The browser hashes the input, sends five hexadecimal characters, and checks the returned candidates locally. We build small web tools, and we like this approach because the network boundary is explicit enough to inspect.

Have I Been Pwned provides this pattern through its Pwned Passwords range endpoint. The useful question for developers is what crosses that boundary, what stays in memory, and what the answer actually establishes.

Follow the value through the browser

SHA-1 produces a 160-bit digest, represented here as 40 hexadecimal characters. Split that string into a five-character prefix and a 35-character suffix. Request https://api.pwnedpasswords.com/range/{prefix}, substituting the prefix. The response contains candidate suffixes and their occurrence counts.

The browser compares its own suffix with those candidates. It never needs to transmit the remaining hash characters to finish the lookup.

Value	Where it is used	Sent in the range request?
Original password	Browser input and hashing	No
Complete SHA-1 hash	Browser memory	No
First five hexadecimal characters	Range URL	Yes
Remaining 35 characters	Local comparison	No
Candidate suffixes and counts	Response parsing	Returned by the service

This is the k-anonymity lookup pattern: one prefix identifies a group of candidate hashes rather than identifying the complete hash in the request. It reduces disclosure. It does not make the request anonymous or hide ordinary network metadata from the service.

A browser function you can run

Use this on an HTTPS page or localhost, where the browser's Web Crypto API is available. Call it from a submit handler with the password field's value. For experiments, use a disposable test string rather than a real credential.

async function breachCount(password) {
  const bytes = new TextEncoder().encode(password);
  const digest = await crypto.subtle.digest('SHA-1', bytes);
  const hash = Array.from(new Uint8Array(digest), byte =>
    byte.toString(16).padStart(2, '0')
  ).join('').toUpperCase();

  const prefix = hash.slice(0, 5);
  const suffix = hash.slice(5);
  const response = await fetch(
    `https://api.pwnedpasswords.com/range/${prefix}`,
    { headers: { 'Add-Padding': 'true' } }
  );
  if (!response.ok) {
    throw new Error(`Lookup failed: HTTP ${response.status}`);
  }

  const lines = (await response.text()).trim().split(/\r?\n/);
  for (const line of lines) {
    const [candidate, count] = line.trim().split(':');
    if (candidate === suffix) return Number(count);
  }
  return 0;
}

The function resolves to an occurrence count, or zero if its suffix is absent from a successful response. Network failures reject the promise; unsuccessful HTTP responses throw. A calling interface should catch those errors and show “check unavailable.” Turning a failed request into zero would give an unsupported reassurance.

The optional Add-Padding: true request header asks for padding entries, reducing information exposed through response size. Padding entries have zero counts. Our exact suffix comparison therefore still produces zero for a matching padding entry. The endpoint and padding behavior are documented in the official API reference.

Keep the surrounding interface honest

Preserve the entered string exactly. Trimming whitespace or changing capitalization before hashing checks a different password. The uppercase conversion in the snippet applies only to the hexadecimal representation of the digest, so it does not alter the password itself.

We would trigger this check after an explicit action rather than sending a request for every keystroke. Repeated prefixes from partially typed input disclose more than a single completed check. Keep password values out of URLs, console output, analytics events, and error reports, too.

Local hashing describes this lookup mechanism. It cannot guarantee that every other script running on the page behaves safely. A browser implementation still needs a trustworthy page and careful handling of the input. SHA-1 also appears here for compatibility with the lookup dataset; it is not a suitable recommendation for storing account passwords.

Read the result as one piece of evidence

A positive count says the password appears in the dataset. It does not identify which of the reader's accounts was affected, and the count is not a count of breaches involving that particular reader.

Zero means no match was returned for this check. A new but predictable password can still be weak. Password strength estimation is a separate task, and a time-to-crack estimate depends on assumptions about guessing methods and attack conditions. Neither a score nor an estimated duration is a guarantee.

Our free checker follows the local SHA-1 and five-character-prefix flow. It shows the breach count alongside a 0–100 security score and a time-to-crack estimate, and includes a strong-password generator. We describe those outputs separately so the lookup result does not masquerade as a complete security assessment.

FAQ

Does the service receive my password or its full hash?

In the range request shown above, it receives the first five hexadecimal characters only. The password, full hash, and suffix comparison remain in the browser. That statement concerns this code path, not every possible script on a page.

Is a password safe if the count is zero?

No. Absence from the returned dataset does not establish strength or uniqueness. We would still avoid reuse and choose a long, unpredictable password for each account.

Why use SHA-1 when it is unsuitable for password storage?

Here it creates a lookup identifier compatible with the dataset. Secure password storage has different requirements, including resistance to repeated guessing. Reusing this snippet as a password storage design would confuse those two jobs.

Check a password with our free tool