Free Apple & Google Wallet Pass Scanner

How to scan an Apple Wallet or Google Wallet pass barcode

The most reliable way to test a Wallet pass is to scan the barcode exactly as it appears to the user. The free scanner above reads an Apple Wallet or Google Wallet pass from a screenshot, a pasted image, or a live camera. It returns the barcode format, exact decoded value, and basic content type.

This is useful when you are checking a boarding pass, event ticket, loyalty card, membership card, or coupon before launch. The image and decoded value stay in your browser, so a support screenshot can be inspected without uploading it to WalletWallet.

1. Open the pass. Display the barcode in Apple Wallet or Google Wallet at normal brightness.
2. Capture the complete code. Take a screenshot or position the barcode inside the camera frame, leaving the clear margin around it visible.
3. Scan the image. Upload, paste, or drop the screenshot above, or choose Camera to scan another device.
4. Check the result. Compare the decoded value with the identifier expected by your ticketing, loyalty, or membership system.

Which barcode formats work in Apple Wallet and Google Wallet?

Both Wallet platforms support QR, PDF417, Aztec, Code 128, Code 39, Codabar, and EAN-13. Apple Wallet also lists Interleaved 2 of 5, while Google Wallet limits that family to the 14-digit ITF-14 variant. Google additionally supports Data Matrix, EAN-8, and UPC-A. The scanner recognizes the complete combined list. The table below distinguishes the formats listed by each platform.

Apple expanded its pass barcode list with Code 39, Codabar, EAN-13, and Interleaved 2 of 5. The table below follows the current Apple Wallet barcode reference and Google Wallet BarcodeType reference.

QR vs PDF417 vs Aztec for Wallet passes

QR is a practical default for tickets, loyalty cards, and memberships because phone cameras and dedicated readers handle it well. PDF417 stores more data in a wide rectangular symbol and is common on boarding passes and event tickets. Aztec remains compact without requiring the same white border as QR, which makes it a familiar choice for transport passes. Linear formats such as Code 128 are useful when a pass must work with existing retail or venue scanners.

Platform support is only one part of the decision. Your entrance scanner or point-of-sale hardware must recognize the same format, and the decoded value must match the identifier your backend expects. A successful browser scan is therefore a useful pre-launch check, but it does not replace a test with the production reader.

Why a Wallet pass barcode will not scan

A pass can display correctly in Apple Wallet or Google Wallet and still fail at a gate or checkout. When that happens, scan the same screen with this tool first. The result helps separate an image or format problem from a reader configuration or backend validation problem.

The screenshot is cropped or blurred

Use the original screenshot when possible. Keep the entire barcode and its clear surrounding margin in frame, avoid glare, and do not enlarge a small image until the barcode becomes soft. For a camera scan, clean both screens and hold the devices still while autofocus settles.

The Wallet format and reader configuration do not match

A venue reader may be configured for QR while the pass displays PDF417, Aztec, or a linear barcode. Scan the pass here to identify the visible format, then confirm that the physical reader has that symbology enabled. For Interleaved 2 of 5, remember that Google Wallet specifically expects the 14-digit ITF-14 form.

The barcode value is readable but not valid

Decoding proves that the symbol contains a value; it does not prove that a ticket is active, a membership is in good standing, or a coupon is unused. Those decisions belong to the issuer's backend. Google Wallet can also display rotating QR and PDF417 barcodes, so a screenshot may contain an older value even when it scans clearly.

What this Apple and Google Wallet pass scanner can confirm

A successful result confirms the barcode visible in the supplied image, its detected format, and its exact text or identifier. It cannot infer which Wallet app produced the screenshot because the barcode itself does not reliably contain that information.

The tool does not open an Apple .pkpass package, inspect a Google Wallet Class or Object, verify an Apple pass signature, read NFC credentials, or validate admission and redemption status. These checks require the original pass data or a connection to the issuer's system.

Common ways teams test Wallet pass barcodes

Before launch, scan screenshots from both platforms and verify that they resolve to the same customer, ticket, or membership record. During reader setup, compare the detected format with the formats enabled on the venue hardware. When a customer reports a problem, a screenshot can reveal an unexpected format, an empty value, or an image-quality issue without requiring the original pass package.

This workflow also helps when migrating an existing barcode program into mobile Wallet passes. Preserve the value expected by the current backend, choose a format that works across the required Wallet platforms and readers, then test the installed Apple and Google versions before issuing the campaign.

Scanning a Wallet pass is different from creating one

This page reads a barcode that is already displayed on a pass. If you want to create an Apple Wallet pass from a barcode, you still need to build and sign the Apple pass and create the corresponding Google Wallet Object. The Apple Wallet pass anatomy and Google Wallet pass anatomy guides explain how each platform renders the fields and barcode.