QR menu vs. QR host: what a table code can actually do

Nearly every guest has scanned a QR code at a table by now, and the guest research says most of them still don't like it. This page looks at what a table QR code structurally can and can't do, what guests actually say about the format, and where the accessibility and legal questions sit — separate from any one vendor's product.

What do guests actually think of QR code menus?

Toast's own blind survey of 850 U.S. adults (fielded September 2024) found 81% of respondents prefer a physical menu — and only 1% actively prefer QR codes. Preference for paper rises with age: 90% of guests 55 and older want a physical menu. Among the people who do use QR menus, opinion splits: 23% feel neutral about the experience, 21% call it somewhat easy, 14% call it somewhat difficult.

Asked what specifically turns them off, respondents pointed to small text on the phone screen (26%), the basic friction of having to pull out a phone at all (20%), and unreliable technology (16%). A full 20% said there's nothing they like about QR code menus at all — though 17% did credit them with one real benefit: not having to touch a physical menu that other guests have handled.

The honest caveat on the widely-repeated "3 in 4 restaurants use QR codes" and "roughly half of diners have scanned one" figures that circulate alongside these numbers: we traced several to secondary industry blogs that don't cite a named, dated survey behind them. Where a number in this article has one clear, dated source, we say so; where the underlying study wasn't findable, we've left the figure out rather than repeat it uncritically.

What can a QR code on a table actually do?

Answer: exactly one thing, mechanically — open a link. Everything a guest experiences after that point is determined entirely by what's on the other end of that link, not by the QR code itself.

For most table QR codes in restaurants today, per Toast's own survey population and the broader digital-menu tooling market, what's on the other end is a static digital menu: a page or PDF displaying names, prices, and descriptions — a paper menu rendered as a webpage. It can be updated without a reprint, and it can carry photos. It cannot answer a question. If a guest wants to know what's in a sauce, whether a dish can be made without dairy, or what pairs well with a dish they're considering, a static menu — QR-delivered or printed — has exactly the same answer either way: nothing, until a person walks over.

That's a structural ceiling, not a quality problem with any particular menu tool. No amount of better photography, faster load times, or nicer typography changes what a static page fundamentally is: something to be read, not something that can be asked.

Does a QR code menu solve accessibility, or create a new version of the same problem?

Neither format solves this on its own, and it's worth being precise about why — because the honest answer cuts against overselling any digital menu, including ours.

The controlling legal precedent is Robles v. Domino's Pizza, LLC, 913 F.3d 898 (9th Cir. 2019): the Ninth Circuit held that a restaurant's website and app fall under Title III of the Americans with Disabilities Act because they serve as a "nexus" to the physical restaurant — meaning the same accessibility obligations that apply to a dining room's physical layout extend to its digital ordering and menu channels. Domino's asked the U.S. Supreme Court to review that ruling; the Court denied certiorari on October 7, 2019, leaving the Ninth Circuit's decision in place (the case itself was later decided against Domino's at the district court under California's Unruh Act, on summary judgment, in June 2021). Food-service and hospitality businesses are consistently named among the most frequently targeted industries in the ADA digital-accessibility litigation that has followed — though the specific lawsuit-count figures compiled by ADA-compliance vendors move often enough, and are commercially interested enough, that we haven't repeated any single one here as a citable statistic.

The practical guidance that follows from that precedent, echoed consistently across accessibility standards writing: a QR code should never be the only way to reach the information it points to — but what counts as an equivalent path depends on where the code actually is. At a table or in a window, there's a fixed physical location and, in a working restaurant, staff nearby: a printed backup menu and a staff member who can read it aloud are both realistic, and a restaurant that removes its paper menu because it has a QR code hasn't solved accessibility there, it's relocated the exclusion. On a receipt, in a shared link, or on a website, neither of those is available — there's no table to return to and often no staff in the loop — so the equivalent path there has to be the digital surface itself, built to work with a screen reader, not a printed page nobody is present to hand over. That's true whether what's behind the code is a static PDF or a live conversational host: a phone-based experience is still a phone-based experience, and which fix actually reaches the guest depends on the placement, not the format.

So what's the actual comparison — a QR menu, or a QR host?

Not "QR code or no QR code." Every format here starts with the same square of black-and-white pixels on the table. The comparison is about what happens after the scan — and what that changes for the guest who has a question a static page can't answer.

A static QR menu answers the question "what's on the menu" and stops there, regardless of price or polish. It cannot tell a guest what's in a dish, resolve an allergen question in the venue's own words, or take a private complaint away from the table — because none of those are display problems, and a display is all a static menu ever was.

A QR-linked host changes what's possible after the scan without changing the QR code itself. Where our own product sits: the free page underneath the code — the menu, the tabs, the private line to management, the praise door, the events enquiry — carries no AI and costs nothing, for as long as the venue runs it (the honest floor: free is what the guest tells the venue, not what the venue's paid host does). What the paid tier adds is the specific thing a static menu structurally cannot do at any price: a guest can actually ask a question about a dish, in their own language, and get an answer grounded in what the venue provided. That's the one line this whole comparison comes down to — a QR code has always been capable of opening a page; whether that page can hold a conversation is a separate decision, made after the scan, that a restaurant is free to make either way.