QR CODE MENU
Create a QR code menu
A QR code menu is two things: your menu published as a PDF or a web page, and a QR code on the tables that points at it. Because the code points at an address you control, changing a price means uploading a file rather than reprinting every table card.
Free plan, free SSL, no credit card.
- 0
- table cards to reprint when a price changes
- 2
- steps: publish the menu, download the code
- 1
- code to print, however often the menu changes
- 5,000
- menu opens a month on the free plan
How it works
Three steps, start to live link
-
Publish the menu
Upload it as a PDF or as a web page and publish to an HTTPS address guests can open on any phone, with no app.
-
Download the QR code
Open the site in your dashboard and download its QR code as an image ready for table cards, windows and boards. Included on every plan, including the free one.
-
Change the menu, not the cards
Upload the new menu and every printed code keeps working, because the code encodes the address rather than the file.
The plain answer
What makes a QR code menu work in practice?
One thing: the code has to point at an address you control, not at a file. A QR code cannot be edited after it is printed, so whatever address goes inside it is the address for the life of the table card. If that address serves whatever menu you last uploaded, prices can change on a Tuesday and nothing on the floor has to be touched.
This is where the common setup quietly fails. Uploading the menu to a cloud drive and generating a code from that link works until the day someone uploads a new menu as a new file, which creates a new link and orphans every code in the room. It also fails if the free code generator you used routes through its own redirect and later decides that redirect is a paid feature.
The other decision is PDF or web page. A PDF is faster to publish if you already have a designed menu, and it looks exactly like the printed one. A web page reads better on a phone, because a PDF made for A4 needs pinching and scrolling on a small screen. Both publish the same way and both get a code, so the honest answer is to use whichever you already have, and revisit it if guests complain about zooming. Publishing a PDF as a web page covers the first route.
Who it is for
The people who reach for this
-
Restaurants and cafes
A menu on every table that can change with the specials, without a print run.
-
Bars and event venues
A drinks list or an event programme that changes weekly and is scanned from a board.
-
Hotels and short lets
A house guide, a breakfast menu or local recommendations, scanned in the room.
-
Food trucks and markets
One code on the counter, one menu you can rewrite between locations.
In detail
What you actually get
Prices change without a reprint
This is the entire economic case for a QR menu, and it only holds if the address behind the code is stable.
- Upload a new menu and every printed code points at it immediately.
- No re-generating, re-laminating or replacing table cards.
- From Pro, you can put yesterday's menu back in one click.
Guests need nothing but a camera
A menu that requires an app, an account or a cookie banner is a menu people give up on and ask a member of staff about instead.
- Modern phone cameras read QR codes natively; no app to install.
- The menu opens in the phone browser over HTTPS, so no security warning appears.
- No sign-in and no account, for guests or for staff.
A code that prints properly
A code is scanned in bad light, at an angle, on a laminated card. It has to be a clean image at the size you actually print.
- Downloads as an image that scales up for table cards, windows and A-boards.
- Generated for the site address, so it stays valid as long as the site does.
- Included on every plan, including the free one, and publishing the menu itself is free.
Your own address on the code
Some phones show the destination before opening it, and a guest reading your venue name there is a small but real difference.
- Connect a domain you own from Pro, $15 a month.
- Or pick a readable subdomain for free.
- DNS guides for the common registrars.
No card required
What the free plan includes
Hosting the menu is free. What the free plan gives a venue, in full:
- 1 live site on a real free plan, not a trial of a paid one, and no card to start.
- Up to 25 MB per upload and 25 MB of storage across the account.
- 5,000 visits and 5 GB of traffic a month.
- HTTPS with a real certificate, issued and renewed for you.
- Up to 15 publishes a day, so you can iterate without asking permission.
- The deploy-time security check, which reads what you published and warns about a stray .env file, a .git folder, a private key or an API key left in your JavaScript.
- A small Droply badge in the corner of the page. Removing it starts on Starter.
- Free sites are served noindex, so search engines do not list them. Search visibility starts on Starter.
- A downloadable QR code for the link, so it can go on something printed.
A hosted menu vs a drive link plus a QR generator
How this compares with the usual two-tool setup
Most venues upload the menu to a cloud drive and paste that link into a free QR generator. It costs nothing on day one. These are the places it costs something later.
| Droply | Drive link plus a QR generator | |
|---|---|---|
| What the code encodes | An address you own and control. | A drive URL, or the generator's own redirect. |
| Changing the menu after printing | Upload a new file; every printed code still works. | Only if you use Manage versions to replace the file in place. A fresh upload mints a new link. |
| What a guest sees on opening | The menu. | The drive viewer, and a You need access screen if the share is restricted. |
| Dependency on a third party | One account, one address. | Two services, either of which can change terms. |
| Menu as a web page rather than a PDF | Both supported the same way, both get a code. | A drive is built around files, not pages. |
| Cost | Free to publish, and QR codes are included on every plan, including the free one. | Usually free, with a tracked-code upsell. |
| Rolling back a bad menu upload | From Pro, one click. | Restore a previous version, if it has not passed the 30-day or 100-version cutoff. |
| Tools that have to keep working | One. | Two. |
Google Drive rows checked 8 September 2026 against Google's own Drive help pages: managing versions (Manage versions, then Upload new version; a version may be deleted after 30 days or once there are 100 newer ones unless you choose Keep forever), sharing and expiration (an expiry date is set per person, under the options for work or school accounts, not on an anyone-with-the-link share), and the You need access screen a person sees without permission. The rows describe how each approach behaves rather than what anyone charges. Product behaviour can change.
When Droply is the wrong choice
This publishes a menu and gives you a code for it. A venue that needs more than that should buy a system built for venues.
- You want guests to order and pay from the menu. That is a point-of-sale integration, not a hosted document.
- You need per-table codes so the kitchen knows where an order came from. Every table would need its own address here, which is not what this is for.
- You want the menu to show live stock, sold-out items or allergen filtering. That needs an application behind it.
- You need a database, a login system, or code that runs on the server. Droply serves files; it does not execute your application.
- You want a build to run on every push to a repository. Droply has no Git integration and no CI: you build locally and upload the result.
- You are running WordPress or another PHP application. A static export of it can be hosted here, but the application itself cannot.