Skip to content
Security Tool

QR Signature Note Builder

Build a signed-URL verification note: the exact payload, its real SHA-256 checksum computed in your browser, the issuer, and step-by-step instructions a recipient can follow to check the code. Send the note through a channel separate from the code.

1. Describe the signed code

Example: https://example.com/ticket/REF-99104

Example: Riverside Museum

Example: A published phone number — not one printed on the suspicious item.

Verification note

Signed QR code — verification note Issuer: (name of the organisation or person who issued this code) Issued: (issue date) Issuer contact: (a phone number or address the recipient already trusts) Payload (exact text encoded in the QR code): (enter the payload) SHA-256 checksum of the payload: (computed from the payload above) How to verify: 1. Scan the QR code with a scanner that shows the decoded text (do not open the link yet). 2. Compare the decoded text with the Payload above, character for character. 3. Hash the decoded text with SHA-256 (UTF-8) and compare the result with the checksum above. 4. If both match, the code is identical to what the issuer produced. If either differs, stop and contact the issuer through a trusted channel. Important: this note proves the payload was not altered since it was hashed. It does not by itself prove who hashed it. If authorship matters, ask the issuer how the checksum was signed and which key to verify against.

Send this note through a channel independent of the code — a letter, a known email address, or a page you control.

How a verification note makes a QR code checkable

A QR code asks for blind trust: the recipient cannot read it, so they trust the context around it. A verification note replaces blind trust with a check anyone can perform. The note carries three things: the exact payload, its checksum, and the steps to compare them. The recipient decodes the code without opening the link, compares the decoded text against the note, hashes it, and compares the checksum. Two matches mean the code is identical to what the issuer produced. Any mismatch means stop.

The independent channel is the part that makes the scheme work. A note printed on the same label as the code, or handed over in the same envelope with no other connection to the issuer, proves nothing — an attacker who replaces the code can replace the note. The note must arrive through a route the attacker does not control: a letter from an address the recipient knows, an email from a familiar sender, a page on the issuer's own site. The check compares two independent sources, and independence is what gives the comparison its power.

Precision matters as much as independence. A hash is computed over bytes, so the payload in the note must match the payload in the code exactly — same capitalisation, same punctuation, no trailing space, no line-break difference. That is why this tool computes the checksum from the payload you type, rather than letting you type a checksum from memory. When the recipient checks, they should hash the decoded text directly, not retype it: retyping introduces errors that produce false mismatches, and a verification system that cries wolf will soon be ignored.

Be clear about what the note does not prove. A checksum proves integrity — the payload was not altered since it was hashed. It does not prove authorship. If the recipient needs to know who issued the code, the issuer must sign the checksum with a private key, and the note must say which public key verifies the signature. Many workflows do not need that: a ticket, a certificate, or a handover document where the recipient already knows the issuer only needs integrity. Use signatures when authorship is the question, and say so in the note.

Keep the recipient's side of the workflow light. Four steps, plain language, no jargon, and a clear instruction for the mismatch case: stop, and contact the issuer through a trusted channel. A verification note that takes a minute to follow will be followed. One that reads like a security manual will be skipped — and a skipped check protects nobody.

Frequently Asked Questions About QR Signature Notes

What is a signed-URL note?

A short document that travels with a QR code and lets the recipient verify it: the exact payload, its SHA-256 checksum, who issued it, and the steps to check it. The recipient compares the decoded payload against the note instead of trusting the printed code on its own.

Does a checksum prove who issued the QR code?

No. A checksum proves the payload was not altered since it was hashed; it says nothing about who hashed it. If authorship matters, the issuer should digitally sign the checksum with a private key, and the note should tell the recipient which public key to verify against.

How should the note reach the recipient?

Through a channel independent of the code itself: a letter, an email from a known address, or a page the issuer controls. A verification note printed on the same label as the code proves nothing, because anyone who replaces the code can replace the note alongside it.

What should the recipient do if the checksum does not match?

Stop. Do not open the link, enter credentials, or send money. Contact the issuer through a channel you already trust — a known phone number or address, not one printed on the suspicious item — and report the mismatch with the date, location, and a photo if it is safe to take one.