Should a QR code on a headstone be static or dynamic?

Static, once the destination is settled: free, unlimited, and it works forever with no dependency on OpenQR. Dynamic is worth using while a tribute page is still being built, or if you specifically want a scan count, but treat it as a temporary or add-on choice rather than the default for something going on stone.

What size should a QR code be on a memorial?

Around 40 to 50mm across for a plaque or headstone panel read up close, larger for a bench or memorial tree marker read from further back. That is above the general print-size floor deliberately, to allow for the denser code that error correction level H produces and for a surface that will weather over time.

Will the code still scan once the stone has weathered?

Set error correction to level H before generating. It tolerates roughly 30% of the code being damaged, covered by moss or lichen, or chipped, and still decodes. It is the one setting worth changing from the default for this use case.

Where should the code point if the family does not have a website?

OpenQR does not host tribute pages itself. The usual options are a funeral director's own tribute page, an existing memorial or tribute site the family has chosen, or a shared photo album the family already uses. Point the code at whichever is real today, and repoint later with a dynamic code if it changes.

Can a memorial company or mason create codes for many headstones at once?

Yes. The bulk generator takes a list, one row per memorial, and produces the whole batch as engraving-ready SVG files at an exact millimetre size, rather than working through a single-code form two hundred times.

QR Codes for Memorials, Headstones and Grave Markers

Create a QR code

A blank brass plaque set into the polished corner of a granite headstone.

QR codes for memorials and headstones

A memorial is not a marketing asset with a three-year shelf life. It is granite, bronze or oak, meant to outlast the company that put a QR code on it, so the first honest question from a mason, a family or a council is not "how do I add a code to a headstone" but "what happens to it when nobody is checking on the business behind it". This page answers that first, then covers the practical part: getting a code to survive being engraved into stone, and getting from a list of names to a set of engraving-ready files without proofing two hundred codes by hand.

What happens if OpenQR is not here in fifty years

Nobody can promise a company will exist in five decades, so we will not pretend to. What we can tell you is what happens either way. A static code is a plain image that encodes the destination directly: no account, no redirect service, no dependency on us at all once it is engraved. It works for as long as the destination it points to works, which is a decision the family or mason controls, not something tied to our survival. The generator that makes it is open source under AGPL and can be self-hosted, so the software to produce more codes never disappears even if the hosted site does. A dynamic code adds the ability to repoint the destination later and see how many people visited, but it does that through our hosted redirect service, so it depends on us staying up. If that matters for something going on stone for good, use a dynamic code while the destination is still settling, then bake the final answer into a static code before it is engraved. Either way, a destination is never locked away: every code and where it points is visible in the dashboard and readable back out through the API at any time.

Static or dynamic: pick deliberately, not by default

Most of what applies to any dynamic code (see the dynamic QR code guide) applies here too, but the stakes are different. Reprinting a business card because a link changed costs nothing. Re-engraving a headstone does not happen. Static is the safer default for anything permanently cut into stone: it is free, unlimited, needs no account, and once it is on the memorial nothing about our business affects whether it still works. Dynamic earns its place when the destination genuinely is not settled yet, such as a tribute page still being built, or when a family or memorial company wants a scan count. Free covers 3 dynamic codes; beyond that it is Pro, at £9 a month, which is a sensible cost for a memorial company running many plots and not really the shape of spend a single family should be signing up for.

Engraving a code onto stone

Paper and stone behave differently. A laser or sandblast cut has a minimum feature size below which individual modules smear into each other, the surface will pick up lichen, moss and general weathering over years outdoors, and a chip or crack can take out part of the code the way a scratch takes out part of a label. None of that is a reason not to do it. It is a reason to size and set the code deliberately rather than exporting whatever the tool defaults to.

Stone or plaque finish	What tends to happen	What to do about it
Polished granite	High gloss reflects light and can wash out a shallow cut in bright sun	Cut deeper, or infill the code with a contrasting enamel or paint rather than relying on polish sheen alone
Matte or flamed granite	Scatters light and generally reads well as cut	A plain laser etch usually needs no infill
Sandblasted lettering	Coarser than a laser, so small modules blur	Keep the code larger than you would for a laser cut, and test one block before committing to a run
Bronze plaque	Cast or etched detail develops a patina over years that can flatten contrast	Recess deep enough that the patina sitting in the grooves still reads darker than the raised surface

Use error correction level H, not the default

Level H lets a code still decode with roughly 30% of it damaged, obscured or missing, versus about 7% at the default level. On a surface that will be rained on, grown over and occasionally chipped for decades, that difference is the one between a code that keeps working and one that needs re-cutting. It makes the code slightly denser at a given size, which is why it has to be chosen alongside size, not instead of it. See the error correction guide for the full table.

Size follows scanning distance the same way it does anywhere else (the print size guide has the full method), but treat the guide's absolute floor of 2cm as a floor for pristine paper read close up, not for stone. Someone reading a plaque or a headstone panel is usually standing right over it, so 40 to 50mm across is a sensible working minimum once you allow for level H density and a surface that will not stay pristine. A code on a bench or a memorial tree marker, read from further back, should scale up from there using the same distance-based rule as anything else printed outdoors.

One code per memorial: the mason's and memorial company's workflow

The test is the same one that decides it for any tagging job: does every code need a different destination. It does here, always, because every code belongs to one memorial. The bulk generator takes a pasted or uploaded list, one row per memorial, and produces the whole batch at once rather than two hundred trips through a single-code form. Give it a name column to label each file and a destination column if the pages already exist, generate at the size and error correction settled above, and export as SVG at an exact millimetre size so what goes to the engraver's software is the size you actually specified, not something scaled up from a screen export.

From a spreadsheet of names to an engraving-ready file

1
Build the list
One row per memorial: a name to label the file, and a destination if it already exists.
2
Decide static or dynamic, deliberately
Static for anything final and going straight on stone. Dynamic only while a destination is still being decided.
3
Set size and error correction for the surface
40 to 50mm or larger depending on finish and reading distance, error correction H.
4
Export as SVG at the millimetre size you need
Vector, so the engraver's software cuts the exact size specified rather than resampling a raster file.
5
Proof a physical sample before the run
Cut or print one on the actual material and scan it in normal daylight before committing two hundred headstones to it.

Where the code should point, if there is not a tribute page yet

OpenQR does not host a tribute page, a memorial profile or anywhere for photos and messages to live: that is a genuinely separate decision, and not one we have made for this product. If a destination does not exist yet, the usual answers are a funeral director's own tribute page (most now offer one), an existing memorial or tribute site the family has already chosen, or simply a shared photo album or folder the family already uses. Point the code at whichever of those is real today, and if it changes, a dynamic code lets you repoint it without touching the stone; a static code means choosing the destination once, correctly, before it is cut.

Who buys this, and why the competition is not who it looks like

Demand here is modest and specific: 210 searches a month in the UK, 880 in the US, for terms clustered around putting a QR code on a memorial. Competition for those terms is high, but almost all of it is monumental masons and plaque sellers competing to sell the physical hardware, not code services: a $1.24 average cost per click says nobody is bidding to sell the software layer. That is an opening rather than a wall, particularly for a mason or memorial company who already sells the plaque and could add the code as part of the same order rather than losing the customer to a separate errand. Buyers in practice are monumental masons, memorial and headstone companies, crematoria and councils commissioning benches or memorial trees, and occasionally a family ordering directly for one memorial.

What the scan record shows, and the tone to use about it

Every scan of a dynamic code is counted, with a date and a rough location, and that is genuinely useful here: a family who cannot visit often can see that someone did. Describe it plainly. This is how many people visited, not a conversion rate, an engagement metric or anything else borrowed from marketing, because that language is wrong for a headstone in a way it would not be for a shop sign. No individual scanner is ever identified, and no location is named below five scans in the window, so nobody is watching a specific person visit a grave.

This is bereavement data, not a growth metric

If you manage codes for many memorials on behalf of clients, resist the instinct to summarise scans the way you would summarise clicks on anything else. A quiet code is not underperforming; it may simply belong to someone with fewer people left to visit. Report the number, skip the framing.

A static code keeps working regardless: it is a plain image encoding the destination directly, with no dependency on us. A dynamic code depends on our hosted redirect service staying up, which is why we recommend static for anything permanently engraved. The generator itself is open source and self-hostable, so the software to make more codes never disappears even if the hosted site does.

Make the whole set at once

The bulk tool opens seeded with the shape of this job: example rows in your vocabulary, and the filename pattern that suits it. Free, unlimited and with no account for static codes.

Open the bulk generator