There is a post on r/unpopularopinion titled “The QR Code Menus are Better than Paper.” The author’s argument is simple: they would rather touch the phone screen they clean religiously than a laminated menu that has been pawed over with “spittle-covered fingers since it was wiped down last week.” Especially right before eating.

It earned its flair. The comments (111 of them, and counting) largely disagree, and if you have ever watched a table of adults squint and pinch at a phone screen while a server waits, you know why.

Here is the thing, though: both sides are arguing about the wrong object. Almost every complaint in that thread is not about the QR code at all.

What people actually complain about

Read the anti-QR-menu arguments closely and a pattern shows up:

• “It takes forever to load.”
• “You open it and it’s zoomed out to the whole page.”
• “You have to pinch and drag sideways to read the prices.”
• “I lose my place every time the screen locks.”

None of that is a QR code problem. A QR code is just a link you scan instead of type. Every one of those complaints describes what happens after the link opens, and what usually opens is a PDF: the restaurant’s print menu, exported from a design file, uploaded as-is.

A PDF is a paper format. It has a fixed page size, print-sized type, and multi-column layouts, because it was designed to be printed. Serving it to a phone screen is like handing someone a broadsheet newspaper through a mail slot. The QR code gets the blame, but the PDF is the villain.

What the pro-QR side gets right

The germaphobe argument is real (laminated menus are wiped, at best, occasionally), but the stronger argument belongs to the owner, and it barely came up in the thread.

A menu is the most frequently edited document a restaurant owns. Prices move. The fish changes. A dish sells out at 7pm on a Friday. With paper, every one of those edits means reprinting, and with a laminated menu it means living with the wrong price until the next print run.

A QR code fixes this only if the thing it points to is actually editable. A QR code pointing to a PDF is the worst of both worlds: paper’s update problem wearing a phone’s screen.

What a good QR menu looks like

The fix is boring: the QR code should open a fast, mobile-first web page.

• It loads in about a second, even on weak reception, because it is text and styles, not a 6 MB print file.
• Type is phone-sized. Sections read top to bottom. No zooming, no sideways scrolling.
• No app, no account. It opens in the browser like any link.
• When you edit it, the printed QR codes do not change, because the link did not change. The code on table 12 serves the new price the moment you save.

That last point is the whole trick. Print the QR code once. Edit the menu forever.

How to make one (about ten minutes)

I built a restaurant menu starter widget for exactly this, so the honest disclosure is: this is my product. The steps, though, work as a checklist for whatever tool you use.

1. Start from a menu layout, not a blank page. The starter has sections (starters, mains, drinks), and each line is just Name | Price | Description | Tag, so a V or GF badge is one word.
2. Make it yours. Rename sections, paste in your items, set your colors. In Fugte you can also just describe the change and AI edits it.
3. Publish, then decide what the code points at. This is the step every hosted QR menu tool decides for you, and it is the one worth deciding yourself. If you have a website, embed the menu on your own menu page and point the code at that page’s address, so a diner who scans lands on your site rather than someone else’s. If you have no website, point it at the hosted widget link, which stands on its own. Either way, pick one and keep it: a code printed on 200 table tents survives years of menu revisions only because the address it encodes never changes.
4. Generate the QR code. Any free QR generator works; Canva has one built in, which is handy if your table tents and stickers are already Canva designs.
5. Print it once. Table tents, window sticker, the bottom of the receipt. You will not be printing it again.

Putting the menu on your own page has a second effect worth having: the menu on your site and the menu on your tables become the same document and cannot drift apart. That fixes the second most common menu complaint, the website menu that has been wrong since 2024.

Where paper still wins

Honesty section. The Reddit author conceded fine dining, and they were right to.

• Fine dining and ambience. A heavy card menu is part of the experience. A phone at the table is not.
• Dead zones. If your dining room gets one bar of signal and you have no guest wifi, QR-only is hostile. (A fast text page survives weak reception far better than a PDF, but “survives” is not a strategy.)
• Guests who don’t want to. Some people do not have a smartphone, ran out of battery, or simply hate it. That is a real preference, not a failure to adapt.

The answer is not either-or. Keep a handful of paper menus for whoever wants one, and let the QR code carry the nightly churn of prices and specials. The paper copies get out of date; the QR ones never do; and the pile of laminated menus you reprint quarterly gets a lot smaller.

The one-line version

QR menus did not fail because scanning a code is hard. They failed because restaurants pointed the code at a print file. Point it at a fast page you can edit in one place, and the germaphobes, the owners, and most of the 111 commenters can all be right at once.

Want the ten-minute version? Start with the restaurant menu widget, publish it, and point a QR code at the link.