Skip to content

QR Menu Opens a Login Page? Fix Restaurant Menu Access

By WE CREATE QR CODE · 7 min · Published

If a restaurant QR code opens a sign-in page or a “request access” screen, the camera has probably read the code successfully. The problem is further along the journey: the address inside the code leads to content that the guest cannot open. Changing the code's colour or printing it larger will not remove that access requirement.

This guide is for a menu that scans but fails to open for customers. If the camera cannot recognise the pattern at all, start with the QR code not scanning checklist. If access already works and you only need to change dishes or prices, use the separate guide to updating a menu without reprinting.

Find out which part of the journey failed

Ask the person reporting the problem what appeared after scanning. “It does not work” can describe several different failures. Record the destination address and the message on the screen without asking a customer to share passwords or other private information.

What the guest seesWhat to investigate first
No link appears in the cameraPrinted pattern, lighting, border and scanner support
A sign-in or request-access pageFile permissions and whether the link is intended for visitors
A website editor or management dashboardAn administrative link copied instead of the published menu
A missing-page messageMoved file, removed page or an incorrect address
The wrong or previous menuThe actual encoded destination, publishing state and caching
A Wi-Fi sign-in screenThe guest network's connection process
A browser security warningThe destination's HTTPS configuration; do not ask guests to bypass it

These are starting points, not diagnoses from the message alone. For example, a missing-page message can sometimes conceal a permission problem. Keep the exact address in your notes so that the person who maintains the menu can reproduce the same route.

Read the address from the printed card

Begin with a table card that is actually in use. The design file on a manager's laptop may contain a newer code than the cards in the dining room. Where your scanner provides a preview, inspect the address before opening it. If the link looks unfamiliar or suspicious, remove that card from service and have the responsible person check it.

Compare the address with the restaurant's approved public menu link. A publishing tool may offer several links: an editor URL, a preview, a file-sharing URL and the public page. They can all work for the signed-in owner while giving guests different results. Do not decide that a link is public just because its text contains the word “menu”.

Our menu QR generator stores the address you enter. It does not log guests into a service, upload a menu or change a document's sharing settings. The PDF QR generator also takes a link to a file hosted elsewhere. A correctly generated code can therefore point to a private document.

Test without the owner's signed-in session

Open the exact destination in a browser session that is not signed into the account that owns the menu. A private browsing window can help, but do not then sign in to “make the test work”: that would remove the condition you are trying to check. A second device without a staff login is a useful additional test.

Try mobile data as well as the restaurant's Wi-Fi. If the menu opens on mobile data but the Wi-Fi connection leads to a network sign-in page, investigate guest connectivity before changing the menu file. If it fails on both connections, continue checking the destination. This comparison narrows the investigation; it does not establish the cause by itself.

For a public menu, a guest should be able to reach the relevant information without access to a staff account. If an ordering service intentionally requires an account at checkout, separate that from the basic menu-reading journey. Decide whether visitors can browse dishes and prices first, and label the purpose of the code accurately.

Publish a customer copy with appropriate permissions

Keep the menu guests should see separate from the working document. A staff file may contain supplier costs, internal comments, draft prices or other information that should not be published. Create an approved customer version before widening access. Do not make an entire staff folder public just to fix one menu link.

For Google Drive, the official sharing instructions distinguish restricted access from “Anyone with the link” and offer Viewer, Commenter and Editor roles. For an approved public menu, viewing access is normally the relevant role. Check the file's General access settings, choose the intended audience and copy its sharing link. Work or school administrators can restrict external sharing. Google also notes that the owner's name and email can be visible when a file is shared by link.

Those steps are specific to Drive. Other hosts may use different controls or require a separate publishing action. Follow the host's documentation and repeat the signed-out test after saving. If organisational policy prevents public sharing, use an approved website or publishing service; do not try to get around that restriction.

Decide whether the existing print can be kept

There are two distinct repair paths. If you can fix access at the exact address already inside the code, the current printed image may remain useful. If the correct menu needs a different address, changing the text in the generator does not update cards already printed.

When the restaurant controls its own domain, a maintained menu page can provide a stable destination while linking to the current document. For example, https://example.com/menu is a placeholder for a restaurant-owned address, not a hosted menu supplied by this tool. The person maintaining that site can decide whether an old URL can safely redirect to the intended page. Keep redirects short and test the final destination.

If you do not control the old address and cannot preserve it, generate a replacement code, update the artwork and withdraw the old cards. Keep a record of which version is on each counter, table or window. Leaving both versions in circulation makes intermittent complaints harder to investigate.

Check the whole menu after access is restored

An accessible file can still be the wrong file. Read the title, dishes, prices and service times after arriving through the QR code. A café with separate breakfast and evening menus should make that distinction visible. For a venue serving travellers, identify currency clearly; a dollar symbol alone may be ambiguous between US, Canadian and Australian prices. Use the venue's actual currency rather than changing it to match the visitor's device.

Check every language or PDF link that guests can select. An English landing page may open correctly while a second-language menu still points to a private file. Test links as a visitor, without publishing automatic translations of ingredient or dietary claims that nobody has reviewed.

Read the menu on a small screen. Check that text remains usable, links have understandable labels and any consent notice can be dismissed or managed without hiding the menu indefinitely. A PDF designed for a large sheet may need repeated zooming; a readable webpage with a printable PDF as an alternative can be easier to maintain for both uses.

Use a short reopening checklist

Before returning the cards to service, record a pass for each of these checks. This is a suggested operating checklist, not a claim that we tested your restaurant's menu or every type of phone.

CheckEvidence to record
Card and versionWhich physical print was scanned
DestinationEncoded address and final page reached
Guest accessOpens without a staff login on the tested device
ConnectivityResult on venue Wi-Fi and mobile data
Menu accuracyCorrect service, prices, currency and language links
ReadabilityText and links usable at the tested screen size
FallbackCurrent printed menu or staff assistance available
ResponsibilityWho checked it and when to check again

Retest after a file move, a permissions change, a website migration or a change of account ownership. Include the menu destination in your routine opening checks when practical. Keep a printed option available for guests who cannot scan or do not want to use their phones.

Once access is reliable, review the print-size and placement guide before ordering replacement artwork. For campaign reporting, the measurement guide explains the difference between a website visit and a QR scan. An accessible menu, a successful scan and an order are three different outcomes; verify and measure the one you actually need.

Frequently asked questions

Why does my menu QR code work for me but not for customers?+

Your browser may already be signed into the account that owns the menu. A customer does not have that permission. Check the exact encoded address in a signed-out browser and review the public menu file's access settings.

Does the QR generator upload or host my PDF menu?+

No. The menu and PDF flows in this tool encode a web address. You must publish and maintain the destination separately. Generating a code does not make a private file public.

Should I give customers edit access to the menu?+

No. Guests normally need to read the published menu. Keep the working document and staff-only information private, and publish a separate customer version with suitable viewing access.

Can I fix a login problem without reprinting the code?+

Sometimes. If the exact address already encoded in the code can be made available to guests, fixing access at that address may preserve the print. If you need a different address and cannot redirect the old one, create a new code and replace the artwork.

Does a successful scan prove that the menu is available?+

No. A scanner can read the address correctly while the destination requires a login, returns an error or shows the wrong menu. Test both the QR image and the page it opens.

Is private browsing a complete guest-access test?+

No. It helps check a session without your usual login, provided you do not sign in during the test. Also test another device and a different connection, such as mobile data, because network and device conditions can differ.

Blog