DEV Community: Colten Jacob

QPI v2: Evolving QR Codes into Trustworthy Physical Data Containers

Colten Jacob — Wed, 14 Jan 2026 20:53:58 +0000

Colten Jacob (2026)

Abstract: Building on the Foundation

Let's be honest—QR codes are underutilized. We've built this remarkable global infrastructure for machine-readable symbols, with error correction baked right into the standard, and we use them almost exclusively as glorified hyperlinks. QPI v1 asked the provocative question: "What if the QR code wasn't a link, but the data itself?" This paper takes that question and runs with it, addressing every practical limitation head-on.

The original QPI specification showed how to encode images directly in QR codes, creating self-contained digital artifacts you could hold in your hand. But the community had questions: "What about larger images?" "How do we prevent tampering?" "Can this actually work in the real world?"

QPI v2 answers: "Yes, and here's exactly how." This isn't just theoretical—it's a complete, robust specification you could implement this week. We'll explore multi-QR chunking, integrated verification, compression optimized for the QR environment, and even tie into the fascinating "Trust on First Scan" model to create something genuinely new: trustworthy physical data.

1. Introduction: From Clever Hack to Robust Standard

The first QPI paper established something important: QR codes can be containers. This simple shift in perspective opens doors to applications we haven't even imagined yet. A printed menu that's machine-verifiable. A concert ticket that contains its own artwork and verification. An ID card where the photo is stored right there in the barcode.

But as with any good idea, the devil's in the details. A single QR code has limited capacity (~3KB max). Real-world images need more space. Real-world applications need security. Real-world users need reliability.

QPI v2 addresses these challenges with elegant solutions that respect the constraints of the medium. We're not trying to turn QR codes into something they're not—we're discovering what they could be with careful engineering.

2. The Core Insight: Physical Data has Different Rules

Before we dive into the technical details, let's establish a philosophical principle: Physical data transmission has different constraints than network transmission.

On the internet, we assume:

· Essentially unlimited bandwidth
· Bidirectional communication
· Reliable delivery
· Server-side processing

In the physical world with QR codes:

· Each scan is a one-shot transmission
· No retries unless you rescan
· Error correction is baked in but finite
· The medium itself can be damaged

QPI v2 is designed for this reality from the ground up.

3. Chunking: Breaking the 3KB Barrier

3.1 The Problem Everyone Noticed

Let's address the elephant in the room first. The original QPI paper showed that a single QR code could store small images: maybe a 32×32 RGB logo or an 80×80 grayscale portrait. Useful, but limited.

But what if we don't limit ourselves to one QR code?

3.2 Distributed QPI: A Simple Yet Powerful Idea

Imagine a large image split across multiple QR codes, like a puzzle. Each piece contains:

A chunk of the image data
Metadata about its position
Information about the whole image

Suddenly, our capacity is N × 3KB, where N is the number of QR codes. A poster with 16 QR codes could store ~48KB of data—enough for a 256×256 color image with compression.

3.3 The Chunking Protocol (Simple Version)

Here's how it works in practice:

[Image Identifier: 4 bytes]
[Chunk Number: 2 bytes] 
[Total Chunks: 2 bytes]
[Image Data: Up to ~2900 bytes]

Why this works beautifully:

Order doesn't matter—scan chunks in any sequence
Partial recovery is possible—get most of the image even if some chunks are missing
Progressive rendering—display what you have as you scan

3.4 Real-World Example: The Restaurant Menu

Consider a restaurant menu encoded as QPI:

· QR Code 1: Header, restaurant info, first category (appetizers)
· QR Code 2: Second category (entrees)
· QR Code 3: Third category (desserts), contact info
· QR Code 4: High-resolution logo, digital signature

Printed on a table tent, customers can scan any QR to get partial info, or scan all four to get the complete digital menu. The restaurant can update by reprinting—no app updates, no server maintenance.

4. Trust and Verification: Beyond Simple Storage

4.1 The Trust Problem

If anyone can create a QPI image, how do we know it's legitimate? A counterfeiter could create a fake ticket QPI just as easily as a real one.

4.2 Introducing "Trust on First Scan" Integration

In a separate article, I explored the "Trust on First Scan" model—a system where the first scan of a physical code establishes a baseline of trust. QPI v2 can integrate this elegantly:

How it works:

Initial trusted scan connects to a verification server (online)
Server returns a cryptographic proof tied to that specific QPI
This proof is cached locally
Future scans can be verified offline against this cached proof

For QPI, this means:

[Standard QPI Image Data]
[Optional: Hash of image data]
[Optional: Cryptographic signature]
[Optional: "Trust Anchor" identifier]

The trust anchor could be:

· A public key distributed with the app
· A hash registered on a blockchain
· A certificate from a known authority

4.3 Practical Security Levels

Not every QPI needs NSA-level security. We define tiers:

Level 1: Integrity Only

· Contains SHA-256 hash of the image
· Ensures the image hasn't been altered since creation
· No authentication of source

Level 2: Source Authentication

· Contains digital signature
· Requires public key distribution
· Proves who created it

Level 3: Time-Bound Trust

· Includes timestamp and expiration
· Prevents replay of old versions
· Useful for tickets, certificates

Level 4: First-Scan Trust

· Integrates with Trust on First Scan model
· Initial online verification caches trust
· All future verifications work offline

4.4 The Beautiful Part: Backward Compatibility

The security data sits after the image data in the byte stream. A simple QPI v1 decoder will:

Read the image successfully
Ignore the extra bytes it doesn't understand
Display the image (without verification)

A QPI v2 decoder with security support will:

Read the image
Detect security footer
Perform verification
Show verification status to user

This means security can be added incrementally without breaking existing deployments.

5. Compression: Making Every Byte Count

5.1 The Reality of 3KB

When you only have 3,000 bytes to work with, every byte matters. A naive RGB image encoding wastes space. QPI v2 includes intelligent compression strategies:

5.2 Mode-Specific Optimization

For photographs (natural images):

· Convert to YCbCr color space
· Chroma subsampling (4:2:0)
· DEFLATE compression
· Result: ~60% smaller than naive RGB

For logos and graphics:

· Optimal palette selection (median cut algorithm)
· Run-length encoding for large flat areas
· Result: Often 80-90% smaller than RGB

For text and diagrams:

· Convert to 1-bit black and white
· Use specialized compression (CCITT Group 4)
· Result: A full letter-sized page in ~5KB

5.3 Progressive Encoding: Graceful Degradation

Here's a clever trick: encode multiple quality levels in the same data:

[Header: 16 bytes]
[Thumbnail: 200 bytes - 32×32 grayscale]
[Medium quality: 800 bytes - adds detail]
[Full quality: remaining bytes]

If you only scan one QR, you get the thumbnail. Scan more, quality improves. This is perfect for:

· Museum exhibits (quick scan for basic info, full scan for details)
· Product labels (basic info visible immediately, specs with full scan)
· Emergency information (critical info first, details if available)

6. Error Resilience: Expecting Real-World Conditions

6.1 QR Codes Are Surprisingly Robust

The Reed-Solomon error correction in QR codes is excellent—up to 30% of the code can be damaged and still read correctly. But QPI v2 adds additional layers:

6.2 Cross-Chunk Parity

Similar to RAID 5 for hard drives or PAR files for Usenet, we can add parity chunks:

Image Data: [Chunk 1] [Chunk 2] [Chunk 3]
Parity Data: [Parity 1] = Chunk 1 ⊕ Chunk 2
             [Parity 2] = Chunk 2 ⊕ Chunk 3

If any one chunk is missing, it can be reconstructed from the others. This means:

· Print the image chunks on the front of a document
· Print parity chunks on the back
· Even if part is damaged, full recovery is possible

6.3 Checksums at Multiple Levels

Byte-level: QR's built-in error correction
Chunk-level: CRC32 for each chunk
Image-level: SHA-256 for complete image
Optional: Error-correcting codes within the image data itself

7. The QPI v2 File Format: Complete Specification

7.1 Header (16 bytes - fixed)

Bytes 0-3:   Magic number "QPI2" (0x51 0x50 0x49 0x32)
Byte 4:      Version (0x02)
Byte 5:      Flags (bit field)
              Bit 0: Compression enabled
              Bit 1: Security footer present
              Bit 2: Multi-chunk mode
              Bit 3: Progressive encoding
              Bit 4: Palette optimized
              Bits 5-7: Reserved
Bytes 6-7:   Image width (big-endian)
Bytes 8-9:   Image height (big-endian)
Bytes 10-11: Total chunks (1 = single QR)
Bytes 12-13: This chunk index (0-based)
Bytes 14-15: Payload length (bytes in this chunk)

7.2 Color Mode Byte

0x00: Reserved
0x01: Grayscale (8-bit)
0x02: RGB (24-bit)
0x03: Indexed-16 (4-bit palette)
0x04: Indexed-256 (8-bit palette)
0x05: Black/White (1-bit)
0x06: YCbCr 4:2:0 (12-bit effective)
0x07-0xFF: Reserved

7.3 Palette Section (if indexed modes)

Immediately follows color mode byte:

· Each palette entry: 3 bytes (R, G, B)
· Indexed-16: 48 bytes total
· Indexed-256: 768 bytes total

7.4 Compression Header (if compression enabled)

Byte 0: Compression type
          0x01: DEFLATE (zlib compatible)
          0x02: QPI-RLE (simple run-length)
          0x03: CCITT G4 (for 1-bit images)
Bytes 1-2: Uncompressed size (big-endian)

7.5 Image Data

· Stored row by row, left to right
· Format depends on color mode
· May be compressed

7.6 Security Footer (if enabled)

Byte 0: Security type
          0x01: SHA-256 only
          0x02: ECDSA signature (64 bytes)
          0x03: Timestamp + signature (72 bytes)
          0x04: Trust anchor reference
Bytes 1-2: Security data length
Bytes 3+:  Security data

8. Implementation: Making It Real

8.1 Decoder Flow

Camera → QR Detection → Byte Extraction → 
Is QPI? → Yes → Parse Header → 
Multi-chunk? → Wait for/assemble chunks → 
Decompress → Verify Security → 
Render Image + Verification Status

8.2 Performance Considerations

On modern smartphones:

· Single QPI decode: < 100ms
· Multi-chunk assembly (4 chunks): ~300ms
· Security verification: < 50ms
· Total user experience: Feels instantaneous

Memory usage:

· Decoding a 48KB image (16 chunks): < 2MB RAM
· Suitable for even low-end devices

9. Killer Applications: Why This Matters

9.1 Self-Verifying Physical Documents

Imagine a university diploma that contains:

· The official text
· The graduate's photo
· The registrar's digital signature
· A link to the online verification (optional)

All in a single scannable area. No separate barcode, no QR that points somewhere else—the credential is the data.

9.2 Tamper-Evident Packaging

Pharmaceutical companies could print QPI codes on medication packaging containing:

· Legitimate product photo
· Batch number and expiration
· Manufacturer's signature

Counterfeiters would need to replicate both the visible packaging and the digital signature—much harder than just copying the box design.

9.3 Disaster-Resilient Information

In areas with poor connectivity:

· Emergency procedures
· Maps of evacuation routes
· Contact information for aid organizations

Printed on walls, distributed on cards. Always available, always verifiable, never dependent on servers.

9.4 Digital-Physical Artifacts

An artist creates a digital piece, then prints it as QPI. The print contains:

· The artwork itself (as thumbnail or full-res if multi-QR)
· Artist's statement
· Certificate of authenticity
· Link to NFT or digital original

The physical print becomes a first-class digital object, not just a reproduction.

10. Challenges and Limitations

Let's be transparent about the trade-offs:

Capacity is still finite
Even with chunking,we're talking kilobytes, not megabytes. QPI won't replace JPEG for family photos. It's for purpose-sized images.
Scanner compatibility
While any QR scanner can read the bytes,only QPI-aware software will interpret them as images. This requires app installation.
Print quality matters
Low-resolution printers,poor contrast, or reflective surfaces can reduce scanning reliability.
Security is only as good as key management
If private keys are compromised,the verification breaks. This isn't unique to QPI—it's true of all digital signatures.

11. The Future: Where Could This Go?

QPI v3 might explore:

· Color QR integration: Using colored modules for higher density (once color QR standards mature)
· Animated QPI: Scanning multiple codes in sequence creates animation
· Interactive QPI: Codes that change based on context or user interaction
· 3D QPI: Using paper texture or special inks for additional data layers

But here's the exciting part: QPI v2 is implementable today with existing technology. No new hardware, no standards committee approval (though that would be nice), just clever use of what we already have.

12. Conclusion: A New Relationship with Physical Data

QPI began with a simple but radical idea: QR codes can be destinations, not just directions. QPI v2 builds on that foundation to create something genuinely useful: a way to store and verify data in the physical world with digital precision.

The implications are profound. We're talking about:

· Democratizing data storage—anyone with a printer can create permanent, verifiable data
· Bridging digital and physical—creating objects that live in both worlds seamlessly
· Enabling offline trust—verification without connectivity

Most importantly, QPI respects the constraints of its medium. It doesn't try to turn QR codes into something they're not. Instead, it discovers what they could be with careful design and a bit of creativity.

This is more than a technical specification—it's an invitation. An invitation to reimagine how data can live in the physical world. To create artifacts that are both human-readable and machine-verifiable. To build systems that work even when the network doesn't.

The code is waiting to be written. The applications are waiting to be built. The future of physical data starts with a simple scan.

For queries and recommendations : coltenjacob2008@gmail.com

QPI — QR-Pixel Imaging

Colten Jacob — Tue, 13 Jan 2026 17:16:15 +0000

Turning QR Codes into Offline, Verifiable Image Files
Colten Jacob (2026)

Abstract

QR codes are universally deployed but are used almost exclusively as pointers (URLs, IDs, payment tokens). This paper introduces QPI (QR-Pixel Imaging), a method for encoding complete raster images directly inside standard black-and-white QR codes. QPI transforms QR from a redirection mechanism into a self-contained physical image file that can be scanned, verified, and rendered without network access. QPI does not modify the QR standard; it defines a data-layer format inside QR’s byte stream.

Problem Statement

Modern QR codes function as indirections:
QR → URL → Server → Image / Menu / Ticket / Logo
This creates four fundamental problems:

Dependency on network access
Centralized control (link rot, content swapping)
No offline authenticity
No permanent data

A printed menu, ticket, or certificate can be photographed, but it cannot be:

cryptographically verified
programmatically compared
versioned
or authenticated

Meanwhile, QR codes already provide:

error correction
alignment
universal camera support
global infrastructure

Yet they are used only as links.

2. Core Idea

QPI inverts the model:
QR → Image Data → Display
Instead of pointing to an image, the QR code is the image.
The QR code becomes:

a physical file
a printable data blob
a machine-readable image

This enables:

offline menus
anti-tamper labels
identity photos
tickets
certificates
maps
diagrams with full error correction and zero servers.

3. Design Goals

QPI is designed to be:

Backward-compatible (works with any QR camera)
Deterministic (same QR → same image)
Offline
Robust to print damage
Machine-verifiable
Simple to implement

QPI does not change QR’s physical appearance.

4. Why Not Just Print the Image?

A printed image is for humans.
A QPI image is for machines.
A QPI image can be:

digitally compared
hashed
authenticated
stored
transmitted
translated
verified

A photograph of a poster cannot do this reliably.
QPI turns paper into a digital artifact.

5. QR Data Model (Important)

QR codes do not store ASCII.
They store bytes (0–255).
ASCII, UTF-8, URLs, and payment data are merely interpretations of those bytes.
QPI defines a new interpretation.

6. QPI File Format

QPI data is stored directly in QR’s byte stream.
All multi-byte values use big-endian order.

6.1 Header (first 8 bytes)

Bytes 0–2 → Magic string "QPI" (0x51 0x50 0x49) → identifies the data as QPI
Byte 3 → Version (0x01 for version 1)
Bytes 4–5 → Image width in pixels
Bytes 6–7 → Image height in pixels
This header allows any scanner to immediately detect a QPI image.

6.2 Color Mode (1 byte)

The next byte defines how to interpret the pixel data:
0x01 → Grayscale (8 bits per pixel)
0x02 → RGB / Truecolor (24 bits per pixel)
0x03 → Indexed-16 (4 bits per pixel)
0x04 → Indexed-256 (8 bits per pixel)

_6.3 Optional Palette (for indexed modes only)
_
If the color mode is indexed (0x03 or 0x04), the palette immediately follows the color mode byte.
Each palette entry = 3 bytes (Red, Green, Blue)
Indexed-16 → 16 entries → 48 bytes
Indexed-256 → 256 entries → 768 bytes

6.4 Pixel Data Stream

Pixels are stored left to right, top to bottom, row by row.
Grayscale → 1 byte per pixel
RGB → 3 bytes per pixel (R, G, B)
Indexed → palette index per pixel
This is the main image content of the QPI QR code.

7. Compression

QPI v1 allows optional compression (future-enabled):
Run-Length Encoding (RLE)
LZ-family codecs
Compression flags are reserved for later versions.

8. Error Correction

QPI relies entirely on QR’s built-in Reed-Solomon error correction.
This gives:

resistance to scratches
resistance to ink bleed
recovery from partial occlusion

No additional parity is required.

9. Capacity

A maximum-size QR (Version 40-L) holds ~3 KB of data.
This allows:

RGB: ~32×32 pixels
Grayscale: ~80×80
Black & White: ~200×200
Indexed logos: Much larger

Enough for:

logos
faces
tickets
maps
menus
fingerprints

10. Decoding Process

Scan QR → extract bytes
Check first 3 bytes = "QPI"
Read width & height
Read color mode
Load palette (if any)
Decode pixel stream
Render image

11. This Is Not “Color QR”

Some proposals use colored QR squares to encode more bits per module.
That approach:

breaks under lighting changes
fails on cheap cameras
fails on printers

QPI keeps QR black-and-white and uses QR’s existing robustness.
QPI increases semantic density, not optical complexity.

12. Security Extensions
(Optional)

QPI supports adding:

digital signatures
SHA-256 hashes
timestamps

These can be appended after pixel data, allowing:

anti-forgery
authenticity verification
trusted visual documents

13. Applications

Offline restaurant menus
Anti-counterfeit labels
Product authentication
Tickets and passes
Government notices
Disaster information
Museum displays
Physical backups of digital images

14. Why QPI Is Novel

QPI converts QR from:
a link to data
into:
a container of data
This creates a new category:
physically portable digital images

For queries or discussions: coltenjacob2008@gmail.com

https://dev.to/colten_jacob_10ec3150930b/making-qr-codes-safe-by-design-a-trust-on-first-scan-model-tofsa-8-46i4

Making QR Codes Safe by Design: A Trust-On-First-Scan Model (TOFS)

Colten Jacob — Mon, 12 Jan 2026 20:35:08 +0000

Making QR Codes Safe by Design: A Trust-On-First-Scan Model
By Colten Jacob, January 2026

QR codes have quietly become one of the most powerful interfaces in modern computing. A single square can initiate a payment, open a menu, log you into an account, or redirect you to a website. Billions of people now scan QR codes every day—often in public places, often without thinking.
That convenience comes with a serious flaw: QR codes were never designed for hostile environments.
They were invented for factories and inventory systems, not for public walls, cafés, and payment terminals where anyone can replace a sticker in seconds. The result is an explosion of QR-based phishing, payment redirection, and fraud.
This article proposes a simple but powerful fix: Trust-On-First-Scan (TOFS) — a model that brings persistent trust and tamper detection to QR scanning, without breaking usability.

The core problem with QR codes

A QR code is not a label.
It is a command.
When you scan it, your phone executes whatever it contains:

open a URL
start a payment
launch an app
download a file

Most scanners do this immediately.
The user has no way to tell whether:

the QR code was changed,
the destination was swapped,
or the sticker was replaced.

This enables what security engineers call a substitution attack:
The attacker doesn’t need to hack the website.
They just replace the QR code.
This is now common in:

parking meters
restaurant menus
UPI posters
event tickets
building entrances

A perfectly valid-looking QR is enough to redirect money, steal credentials, or deliver malware.

Why existing defenses don’t solve this

We already have:

HTTPS
Google Safe Browsing
Antivirus
App sandboxing

But QR attacks slip between the cracks.
Why?
Because most QR fraud uses:

real browsers
real payment apps
real web pages

Just the wrong destination.
Nothing is technically “malware.”
It’s a trust problem, not a code problem.
Borrowing a proven security idea
In computer security, there is a well-known pattern called Trust-On-First-Use (TOFU).
SSH uses it.
Bluetooth pairing uses it.
Some certificate systems use it.

The idea is simple:
The first time you connect to something, you verify it.
After that, changes are treated as suspicious.
What QR codes lack is an equivalent concept.
That’s what Trust-On-First-Scan (TOFS) is.

What is Trust-On-First-Scan?

TOFS is a lightweight trust framework for QR scanning.
It has four parts:
First-scan confirmation
Destination fingerprinting
Local trust storage
Expiry and mismatch detection
Together, they make QR codes tamper-evident.

How TOFS works

First scan = explicit trust When a QR is scanned for the first time, the phone does not immediately open it. Instead, it shows: the full domain the app that will open (browser, UPI, etc.) the protocol (https, upi, etc.) The user taps “Trust & Open.” This is the only time the user has to think.
A fingerprint is created The scanner creates a cryptographic fingerprint from: the QR content the final resolved destination (after redirects) the target application This fingerprint uniquely represents where this QR actually goes.
The fingerprint is stored locally The phone stores:

the fingerprint
the domain
a timestamp
an expiry date

This becomes the trusted identity of that QR code.

Future scans are automatic If the QR is scanned again and the fingerprint matches: it opens instantly no prompts zero friction Just as fast as today’s QR scanning.
If anything changes, the phone warns If the QR is replaced, edited, or redirected: The fingerprint no longer matches. The phone shows: “This QR code has changed. The destination is different from what you previously trusted.” This immediately stops: sticker swaps redirected payment QRs hijacked menu links The attack fails at the scan level.

Why expiry matters

Public QR codes change over time.
Cafés change menus.
Parking operators change vendors.
Websites get sold.
Domains get hijacked.
TOFS includes expiry:

café QR: 30 days
parking QR: 7 days
bank poster: 180 days

When expired, the QR simply requires re-confirmation.
This prevents stale trust from becoming a future vulnerability.
This is not theoretical.
It directly targets how QR fraud works in the real world.
Why this belongs in the OS
A standalone QR scanner app won’t fix this.

People scan using:
Camera app
Google Lens
WhatsApp
Payment apps

TOFS must live in:

Android
iOS
system QR frameworks
UPI QR handlers

Just like HTTPS warnings or download prompts.
It is a platform-level safety layer. This does not replace existing security

TOFS does not replace:

Safe Browsing
antivirus
UPI verification
TLS

It adds what those systems don’t have:
Memory of what a QR was supposed to be.
Firewalls stop bad sites.
TOFS stops wrong sites.

Why this is practical

TOFS requires:

no new QR format
no new hardware
no network calls
no cloud storage

Everything is local.
It’s just:

a hash
a timestamp
a warning screen

That makes it deployable at scale.

Final thought

QR codes won the usability war.
They are everywhere because they are effortless.
But effortlessness without memory is dangerous.
Trust-On-First-Scan gives QR codes something they’ve always lacked:
a sense of identity over time.
That single change turns QR codes from blind commands into verifiable tools.
And that’s how you make a global interface safe.