Putting a whole packing list inside a QR code (no server, no app)

Talekh Hajiyev — Fri, 09 Oct 2026 07:04:06 +0000

Most "smart" box labels are a QR code that points to a URL. Scan it and a web page shows you the contents. That works until the service shuts down, the phone has no signal in a basement storage unit, or the mover's phone blocks unknown links.

For our Moving Planner we went the other way: the QR code is the contents list. No URL, no server, no app. Any phone camera decodes it to plain text.

Here is what that took, in a single offline HTML file.

1. Plain text, UTF-8, byte mode

A QR code in byte mode stores raw bytes. We build the label text like this:

BOX 12 — KITCHEN
FRAGILE · OPEN FIRST

1. Plates — 12
2. Mugs — 6
3. Kettle

and encode it as UTF-8. That matters because the planner ships in 9 languages: a Cyrillic letter takes 2 bytes, a Chinese character 3, so a Russian or Chinese list fills the code much faster than an English one. The library we use (qrcode-generator by Kazuhiko Arase, MIT) lets you pass a UTF-8 byte string directly.

On iPhone and Android the native camera shows the decoded text with "Copy" / "Search" options. Nothing is opened, nothing is fetched.

2. The real limit is print size, not capacity

The spec allows up to 2,953 bytes in a version 40 code with low error correction. That's plenty of text — but a version 40 code is 177 × 177 modules. Printed on a 99 × 68 mm sticker, each module would be well under half a millimetre, and a phone held at arm's length in a dim hallway won't read it.

So the rule we settled on: every module must be at least 0.30 mm wide. For each label size we know how many millimetres the QR gets, so:

function qrFor(text, sizeMm) {
  for (const ec of ['M', 'L']) {          // prefer more error correction
    const qr = qrcode(0, ec);             // 0 = smallest version that fits
    qr.addData(utf8(text), 'Byte');
    try { qr.make(); } catch (e) { continue; }   // too long for this EC level
    const modules = qr.getModuleCount() + 8;     // + quiet zone
    if (sizeMm / modules >= 0.30) return qr;
  }
  return null;   // doesn't fit → show "list too long for this label size"
}

Medium error correction first (survives tape over a corner), drop to Low only if that's what it takes to fit. If neither fits, the label says so instead of printing an unreadable code — you either split the box or pick the larger label size.

3. Things you must not put in the code

A label is public: movers, neighbours, the building lobby. So items can be marked "Hide on label" — they stay in your private list and search, but are excluded from both the printed lines and the QR text.

4. Knowing which labels are stale

Once a label is printed, the list can change. We store a signature of everything that ends up on the label (language, QR text, room name and colour, flags, visible items, packed date). If the current signature differs from the printed one, the box drops back into a "Not printed yet" filter, so you reprint only what changed.

5. Offline single file

Everything — app, 9 translations, QR library, print layouts for A4/Letter and Avery L7165/5164 sheets — is one HTML file. Data lives in IndexedDB with a localStorage fallback, and backup/restore is a JSON file with the photos inlined.

If you want to see the labels: there's a free live demo (no saving or printing in the demo). The full planner is $29 on Gumroad. I'm the founder, so I'm biased — but I'd love feedback on the QR sizing rule, especially from anyone who has printed codes for warehouses.

A web app in one offline HTML file: IndexedDB, a localStorage fallback and a hand-written ZIP

Talekh Hajiyev — Thu, 24 Sep 2026 11:32:55 +0000

I sell a wedding planner that ships as one HTML file. You download it, double-click it, and it runs in a desktop browser with no server, no account and no network. Guest list, seating chart, budget, vendors, timeline, invitations: 17 sections, 9 interface languages, all in a single file of about 1.7 MB (fonts and a few images are inlined as base64).

This post is about the unglamorous parts that made that format work: where the data lives, how it survives a bad day, and how to export a ZIP without a library.

Why a single file at all

The format is the product. The people buying a wedding planner don't want another account, and they'd rather not hand a guest list with names and addresses to a cloud they don't control. A file they own and can copy to a USB stick fits that.

The trade-off: no server means no sync and no "we'll restore it for you". So storage has to be boring and paranoid.

Storage: IndexedDB first, localStorage as a second copy

The whole app state is one plain object. It's serialized to JSON and written to two places on every save:

const DB = {
  db: null,
  open() {
    return new Promise((res, rej) => {
      const r = indexedDB.open(KEY, 1);
      r.onupgradeneeded = e => e.target.result.createObjectStore('kv');
      r.onsuccess = e => { DB.db = e.target.result; res(); };
      r.onerror = () => rej(r.error);
    });
  },
  set(k, v) {
    return new Promise((res, rej) => {
      const tx = DB.db.transaction('kv', 'readwrite');
      tx.objectStore('kv').put(v, k);
      tx.oncomplete = () => res();
      tx.onerror = tx.onabort = () => rej();
    });
  },
  // get / del are the same shape
};

A single key-value object store is enough. I'm not querying guests by index. I load everything once and keep it in memory, so IndexedDB is just a bigger, async localStorage here.

Saves are debounced, and both writes are attempted independently:

function save() {
  S.updatedAt = Date.now();
  clearTimeout(saveT);
  saveT = setTimeout(persist, 350);
}

async function persist() {
  const raw = JSON.stringify(S);
  let idb = false, ls = false;
  try { await DB.set('state', raw); idb = true; } catch (e) {}
  if (raw.length < 4.5e6) ls = writeLocal(raw);   // stay under the ~5 MB quota
  if (idb || ls) showSaved();
  else showNotSavedDownloadBackup();              // loud, clickable warning
}

function writeLocal(raw) {
  try {
    localStorage.setItem(KEY, raw);
    return localStorage.getItem(KEY) === raw;      // read-back check
  } catch (e) { return false; }
}

Two details that mattered:

The read-back check. setItem succeeding doesn't guarantee what you read later is what you wrote. Comparing immediately is cheap.
Failure is visible. If both writes fail, the "Saved ✓" indicator turns into a red "Not saved — download backup" link. Silent data loss is the worst outcome for this kind of app.

Loading: pick the newest copy that parses

On startup the app reads both copies, throws away anything that doesn't parse or validate, and keeps the most recent one by updatedAt:

async function load() {
  const cands = [];
  try { await DB.open(); const r = await DB.get('state'); if (r) cands.push(r); } catch (e) {}
  try { const r = localStorage.getItem(KEY); if (r) cands.push(r); } catch (e) {}

  const parsed = [];
  cands.forEach(raw => { try { parsed.push(normalizeState(JSON.parse(raw))); } catch (e) {} });

  if (parsed.length) {
    parsed.sort((a, b) => b.updatedAt - a.updatedAt);
    S = migrate(parsed[0]);
  }
}

If IndexedDB is unavailable or its copy is corrupted, localStorage wins, and the other way round too.

Backups are a feature, not a setting

Browser storage can be cleared by the user, by a privacy tool, or by the browser under storage pressure. So the planner treats a JSON backup file as the real source of truth: there's an "Export full backup" button, the last backup date is stored in the state, and the dashboard nags you if you haven't backed up for 14 days.

Importing a backup is the risky path, so it goes through the same normalizeState() as loading:

it rejects anything that isn't an object with settings,
it rejects backups from a newer schema version instead of half-reading them,
it fills missing collections with defaults, so a backup from an older version still opens.

Before replacing the current data, the app stashes the current state under a separate key, so "Restore previous state" can undo an import made by mistake.

A ZIP writer in ~30 lines

One feature exports a personalised invitation PDF for every guest. Downloading 120 PDFs one by one is not an option, and pulling in a ZIP library felt heavy for a single-file app. The ZIP format with no compression ("stored") turns out to be small: a local header per file, a central directory, an end record, and a CRC-32.

const CRC_T = (() => {
  const t = new Uint32Array(256);
  for (let n = 0; n < 256; n++) {
    let c = n;
    for (let k = 0; k < 8; k++) c = c & 1 ? 0xEDB88320 ^ (c >>> 1) : c >>> 1;
    t[n] = c >>> 0;
  }
  return t;
})();

function crc32(b) {
  let c = 0xFFFFFFFF;
  for (let i = 0; i < b.length; i++) c = CRC_T[(c ^ b[i]) & 255] ^ (c >>> 8);
  return (c ^ 0xFFFFFFFF) >>> 0;
}

function makeZip(files) {               // files: [[name, Uint8Array|string], ...]
  const enc = new TextEncoder();
  const le16 = n => [n & 255, n >> 8 & 255];
  const le32 = n => [n & 255, n >> 8 & 255, n >> 16 & 255, n >>> 24 & 255];
  const parts = [], cd = [];
  let off = 0;

  files.forEach(([name, body]) => {
    const nm = enc.encode(name);
    const data = body instanceof Uint8Array ? body : enc.encode(body);
    const crc = crc32(data);
    // local file header: signature, version, flags (bit 11 = UTF-8 names), method 0 = stored
    const h = new Uint8Array([80,75,3,4, 20,0, 0,8, 0,0, 0,0,0,0,
      ...le32(crc), ...le32(data.length), ...le32(data.length), ...le16(nm.length), 0,0]);
    parts.push(h, nm, data);
    // central directory entry points back to the local header offset
    cd.push(new Uint8Array([80,75,1,2, 20,0, 20,0, 0,8, 0,0, 0,0,0,0,
      ...le32(crc), ...le32(data.length), ...le32(data.length), ...le16(nm.length),
      0,0, 0,0, 0,0, 0,0, 0,0,0,0, ...le32(off)]), nm);
    off += h.length + nm.length + data.length;
  });

  const cdLen = cd.reduce((s, x) => s + x.length, 0);
  const eocd = new Uint8Array([80,75,5,6, 0,0, 0,0,
    ...le16(files.length), ...le16(files.length), ...le32(cdLen), ...le32(off), 0,0]);
  return new Blob([...parts, ...cd, eocd], { type: 'application/zip' });
}

The same function also builds the Excel export: an .xlsx file is just a ZIP of XML files, so the planner writes [Content_Types].xml, the sheet XML and friends as strings and hands them to makeZip().

PDFs are already compressed internally, so skipping deflate costs almost nothing in size. The flag 0,8 (bit 11) marks filenames as UTF-8, which matters when guest names are in Cyrillic, Arabic or Chinese.

The limits are the usual ones for this shortcut: no ZIP64, so stay under 4 GB and 65,535 entries. That's not a problem for wedding invitations.

What I'd tell someone trying this format

Keep the state as one serializable object. It makes saving, backups, undo and migrations the same problem.
Write to two stores and load the newest valid one. It costs a few lines and covers most "my data is gone" cases.
Version your state from day one (v: 2 in my case) and refuse to read backups from the future.
Make save failures loud. Offline apps have no support team behind them.
Test on file://. Some APIs behave differently when the page has no real origin, so test the downloaded file itself, not only a dev server.

If you want to see how this feels in practice, there's a live demo with exports disabled. The product itself is SpectrTech Wedding Planner, a one-time purchase.

This article was written with the help of AI. The code excerpts are from the shipping product, lightly reformatted for reading.

DEV Community: Talekh Hajiyev