
Learn how to share a PDF menu by link: upload, set access controls, share a trackable URL, replace the file later, and test it on phones.
You've finished updating prices, but your website still shows the old menu and your table cards need a working QR code. To share a PDF menu by link, upload the finished PDF, configure its sharing settings, copy the browser URL, and test it on a phone before distributing it. The important part isn't generating the address. It's making sure guests can read the right menu wherever they open it.
A PDF menu link takes five steps and fits in one sitting when your file is ready.
Finalise the menu file. Put the restaurant name, page numbering, and an updated date on page one. Include a clear description such as dinner menu or catering packages, so guests can identify the document as soon as it opens.
Open LinkShip's PDF to Link tool and upload the PDF. Sign in when prompted to publish the sharing link. Check the file-size limit displayed on the page before starting, especially if the menu contains full-page food photography.
Give the link a recognisable name. A label such as spring-menu-dinner is easier to identify later than an export filename from your designer. Treat the name as an organisational aid, not a promise that a particular custom address is available.
Configure only the access settings the menu needs and your plan supports. An everyday dining-room menu normally needs no restriction. Private catering proposals and wholesale price lists deserve a separate decision.
Create the link, copy the URL, and test it over cellular data. Turn off Wi-Fi on your phone, open a private browser window, and follow the same address a guest will use. Don't print table cards until that test succeeds.
Our underlying workflow is upload, customise the link, share it, then review visits and downloads. The extra preparation and phone test turn that workflow into a restaurant-ready handover.

Send the copied address through a message and open it from there, rather than relying only on your signed-in browser. Then check that every page appears and that the viewer doesn't hide important content behind awkward controls.
If you're weighing a fixed document against a more adaptable menu format, TopFoodApp's guide to QR menu options beyond PDFs provides useful context. Choose based on how guests browse and how frequently your team changes dishes, not just how attractive the exported file looks.
Launch check: The public address should open the menu without an account or app, and page one should make the current version unmistakable.
A heavy or image-only PDF can make a perfectly functional link feel broken. Fix the source file before spending time changing sharing settings.
File size comes first. Our free tier supports individual PDFs up to 25MB. Compress food photographs for screen viewing, crop unused image areas, and avoid exporting every image at print-production resolution. Stay comfortably within the limit rather than treating it as a target.
Keep the text live. Export directly from your design application with selectable text instead of turning each page into a picture. Try selecting a dish name and its price before uploading. If the whole page behaves like a photograph, return to the source document.
A broad, multi-column menu may look excellent on a counter and require constant sideways movement on a phone. Use narrower layouts, readable type, and logical pages for starters, mains, drinks, or catering packages. Don't shrink the entire menu to fit a single sheet.
Page one should identify the restaurant, explain what the file contains, and carry the version date. Keep decorative cover pages out of the way when a guest is trying to find lunch prices.
Pre-upload checklist
Open the export: Check it in different PDF readers for missing fonts, clipped descriptions, and blank pages.
Reconcile prices: Match the approved printed menu and ordering system.
Review dietary information: Confirm allergen and dietary labels are present, readable, and approved by the kitchen.
Name the file clearly: Use lowercase words joined by hyphens, such as spring-dinner-menu.pdf, rather than spaces or internal design codes.
If the PDF looks soft, correct the export. If it loads slowly, reduce image weight. Neither problem is solved by generating a different link.
A shared PDF may be accessible to anyone who has its link unless you protect it. That's appropriate for a dining-room menu: guests should be able to pass it to the person choosing the restaurant.
Use restrictions when the audience or commercial purpose requires them, not merely because the settings are available.
Access controls for a menu link
| Control | What it does | Best use for a menu |
|---|---|---|
| Public link | Anyone with the link can open the PDF | Dining-room menus on tables, websites, and social profiles |
| Password | Requires a password before the menu opens; doesn't encrypt the PDF or revoke downloaded copies | Staff-only or wholesale price lists |
| Expiry date | Stops the link working after the date you set | Seasonal, holiday, or event menus |
| View-count cap | Closes the link after a set number of views | Limited-run promotions |
Keep public menus unrestricted. Asking seated diners to obtain and type a password adds work before they can even choose a dish.
Our password protection is a paid capability for supported shared content. It controls the sharing link, not the PDF itself. Don't assume a password keeps confidential pricing secret after an authorised recipient downloads or forwards a copy.
An expiry date suits an event proposal with a definite end. For a private catering proposal, use password protection on a supported paid share and send the password separately. A password is not named-recipient identity verification. A view-count cap needs particular care: it limits recorded views, not meals sold or promotion redemptions. Passwords, expiry settings, and view limits require a paid plan.
Access restrictions are distribution rules, not a way to retrieve documents people already possess.
Before sharing, test the configured restriction in a private browser window. Try both an allowed and a blocked route where relevant. Confirm availability in your current plan and settings, and make sure a successful test isn't merely your signed-in owner session bypassing the guest's experience.
Keeping the same public address lets your table tents and window decals remain useful after a price change. Our paid single-file replacement capability supports individual PDFs while preserving their public URL. Confirm replacement is available for the existing share before committing money to printed materials.

Export the revision with familiar section ordering and a fresh version date.
Replace the file attached to the existing link, rather than creating another share.
Open the public address on a phone and inspect the date alongside changed dishes and prices.
Reconcile the complete document with the kitchen's current recipe costs and allergen sheet.
Brief front-of-house staff and remove obsolete printed copies from service.
Say a café changes its breakfast combinations but keeps drinks unchanged. Check the drinks pages anyway: a revised export can introduce layout errors outside the edited section.
Replacement applies to supported individual files, including PDFs, images, audio, video, and Markdown. Don't assume the same procedure applies to HTML sites, ZIP archives, image galleries, or audio collections; those have separate capabilities and restrictions.
Browsers may retain an older copy temporarily, and downloaded versions remain with their recipients. If a test shows stale content, reopen the address in a private window and compare the version date before replacing anything again.
For printed branding, you can explore branded QR code options in RecensioAI B.V.’s guide. Keep decoration secondary to scanning reliability. Print a proof and test it after lamination, from the guest's normal seated position, before approving the full run.
Which placement brings people to the menu: the table tent, street-facing window, receipt footer, social profile, or email signature? For placement-level comparisons, publish the menu PDF once per placement, through PDF to Link or the PDF tab of the QR Code Generator, and give each project its own QR code. Each project keeps its own visit and scan counts, so compare those projects rather than assuming one menu link identifies where every visitor saw it. A short link can't point at an existing LinkShip share, so don't wrap the menu URL in extra short links. The trade-off is upkeep: when prices change, replace the file in every placement project.
Use clear project names, such as table-menu or window-menu, and print each QR code from its own project. Separate projects count toward your plan’s active-project limit. UTM parameters are useful only when a separate analytics setup captures and reports them; adding tags does not create a UTM campaign report in the LinkShip dashboard.
![]()
LinkShip provides visit and download counts. Paid plans add available trends, countries, referrers, and device breakdowns. Supported QR projects report QR scans separately from direct visits. Use only the fields shown for your project; do not infer city-level reports, named guests, reading time, or campaign attribution from those totals.
For QR distribution, use the QR Code Generator and verify the scan reporting available for your project. Saving designs and downloading codes are paid capabilities. The walkthrough on tracking QR code scans for a PDF helps distinguish scan activity from ordinary link visits.
Compare equivalent periods: Keep opening hours, placement visibility, and campaign activity in mind when comparing results before and after a reprint.
Investigate weak placements: Check whether staff cover table cards with condiments or whether window glare prevents scanning.
Disclose collection: Explain the visit information your actual setup collects and why, using the service’s privacy information. Dashboard reports are not a complete inventory of collected data; confirm collection details before writing a privacy notice.
A menu open isn't an order, and a scan isn't proof that someone read the menu.
Repeat visits, staff checks, and guests sharing an address can complicate interpretation. Pair menu activity with phone-call logs or point-of-sale information when assessing commercial results. Even then, avoid assigning every sale to the last recorded menu visit.
A PDF isn't accessible just because it opens in a browser. An image-only export may provide no usable dish names or prices to a screen reader, while a text-based export can still have incorrect reading order or inaccessible tables. Test the actual shared document with assistive technology rather than treating a successful upload as proof of accessibility.
Run practical tests on an iPhone with VoiceOver, an Android phone with TalkBack, and a laptop for keyboard navigation. Selectable text is a starting point, not an accessibility certificate.
Accessibility checks for a linked PDF menu
| Check | How to test | Pass when |
|---|---|---|
| Screen reader reading order | Open the link with VoiceOver on iPhone and TalkBack on Android | Dish names, descriptions, and prices are read in logical order |
| Selectable text | Select a dish name and a price on the page | Text selects and copies rather than behaving as a flat image |
| Zoom | Enlarge the page and inspect prices, descriptions, and allergen notes | Prices and allergen notes stay legible without losing content |
| Colour contrast | Measure body text against its background with a contrast checker | Text meets the checker's applicable accessibility criterion |
| Keyboard navigation | Tab through the browser viewer on a laptop | Focus reaches viewer controls in a sensible order |
For a mixed audience, publish the same menu as semantic HTML where possible, with proper headings and meaningful text. Retain the PDF as an optional download for its predictable print layout.
If you keep PDF delivery as the primary route, add document tags, logical headings, correct reading order, structured tables, and alternative text where needed. Don't assume the design application exported those correctly.
Use the guide to making a PDF easy to read on mobile when adjusting the layout. Then repeat the assistive-technology tests on the actual shared document, not only the local original.
For most dine-in restaurants, I'd start with a readable PDF link, a printed short address, and paper menus available on request. Add an HTML version and staff assistance where guests need easier navigation or have limited phone access. A QR code is an access channel, not the menu itself, a distinction reflected in Vite Une Table's guide to restaurant QR menus.
Use this final service checklist alongside the practical guidance for a restaurant menu QR code:
Offer another route: Print a tested short URL beside the code and keep paper menus ready.
Assign assistance: Make sure staff can read prices and allergen notes aloud.
Explain tracking: Add a brief, accurate privacy note.
Own the content: Assign someone to approve prices and allergens before every update. Hosting the file does not verify menu prices or allergen information.
Watch friction: Separate scans from ordinary visits and investigate device-specific difficulties. Visit totals alone can't prove abandonment.
Create the menu link, test it on both iPhone and Android, and print the verified short address alongside the QR code.
Create your menu link with PDF to Link, then test it on iPhone and Android before sharing it with guests. For table cards or signage, use the Dynamic QR Code Generator and test a printed proof before ordering the full run. Saving QR designs and downloading codes require a paid plan.
Join the community
Subscribe to our newsletter for the latest news and updates