Gravity Forms QR Code - WordPress Plugin

Guide to Setting Up and Using Gravity Forms QR Code

Gravity Forms QR Code is useful when a WordPress form needs to do more than collect data and turn it into a scannable code: a ticket, coupon, request number, return-form link, inventory identifier, or contact card. This guide focuses on practical use rather than marketing copy: where to enable the scanner, how to build a QR code from form values, which modifiers to use, how to verify the output, and where mistakes usually happen.

The plugin works through Gravity Forms features you already know: fields, merge tags, notifications, confirmations, and shortcodes. That means the main job after installation is not hunting for a separate "QR field," but choosing the right data source, the right output location, and the field where the scanner should place the scanned value.

This guide is written for site owners, webmasters, content managers, and developers who already use Gravity Forms and want to build a reliable workflow without unnecessary code. Where behavior needs to be extended, I call out whether that approach comes from Gravity Wiz documentation or standard safe WordPress practice, rather than editing the plugin core.

How the Plugin Fits Into Gravity Forms

The key thing about Gravity Forms QR Code is that it does not add a separate data model on top of Gravity Forms. It uses existing form values and turns them into a QR code anywhere Gravity Forms already supports dynamic content. That makes it convenient: you do not have to redesign your form around a new field type. You just need to decide which data should be encoded and where that code should appear.

There are two main sides to how it works. The first is generating a QR code from a field value or a set of values. For that, you use the :qr modifier on a merge tag or the [gpqr] shortcode. The second is scanning a code inside a form. For that, the Single Line Text field settings get an Enable QR Code Scanner option under the Perks tab, and a scan button appears next to the field on the front end.

This approach maps well to real-world workflows. An event ticket can be emailed after registration and scanned at the entrance. An inventory code can be displayed in a PDF or notification and scanned later in a restocking form. A coupon can be generated from a unique identifier and then scanned into another form. In each case, the QR code is not just an image for decoration, but a way to move a specific value from one point in the workflow to another.

Key idea: Gravity Forms QR Code does not replace Gravity Forms. It extends its merge tags and input fields. If you already know how to build a form, notification, and confirmation, most of the setup will feel familiar.

This also explains why the plugin can work alongside other tools in the ecosystem. The developer lists compatibility with places that accept merge tags or shortcodes: confirmations, notifications, Gravity PDF, GravityView, Entry Blocks, and Preview Submission. But "compatibility" should be read carefully here: the code will appear only where the selected tool actually processes merge tags or shortcodes. If a third-party output escapes HTML, strips attributes, or blocks images, you need to test the result separately.

Who This Plugin Is For and When It Is Overkill

Gravity Forms QR Code makes the most sense not as a generic QR image generator, but as a form tool where the QR code is tied to an entry, email, confirmation, or the user's next step. If you just need to create a one-off QR code for a contact page, a standalone generator is simpler. But if the code needs to appear after form submission, depend on selected fields, or later be scanned back into Gravity Forms, this plugin becomes much more useful.

Good Fit Use Cases

The strongest use cases start where there is a unique value: a ticket number, request ID, coupon, tokenized link, SKU, badge number, or contact card. A QR code lets you move that value from an email, PDF, phone screen, or printout back into a form without typing it by hand.

• Event registration where the attendee receives an email with a QR code and a staff member scans it into a check-in form.
• A coupon request form where the code is built from a unique value and later scanned into an order or validation form.
• Inventory workflows where a QR code or other supported barcode helps quickly find a product, SKU, or restock request.
• Creating a vCard from form data so the recipient can save the contact after scanning.
• Integrating with an existing QR workflow where the website needs to accept a value from an external code and store it in a Gravity Forms entry.

When Another Approach Is Better

The plugin may be unnecessary if your QR codes are not connected to form submissions. For example, a static link to a menu page, a company contact card on a poster, or a one-off code for an ad banner is usually better handled by an external service or a simple generator. You should also be more cautious if the workflow requires complex server-side validation, time limits, code reuse rules, copy protection, or an "already used" check. Gravity Forms QR Code helps generate and scan the code, but the business rules around that code still need to be designed separately.

A separate case is high-volume entry control, where dozens of staff members scan tickets at the same time. At that point, the scan button is only part of the solution. The overall setup matters too: staff permissions, form speed, caching, mobile internet stability, duplicate check-in protection, and a clear manual fallback procedure. The plugin handles an important part of the process, but it does not automatically turn a form into a full ticketing system.

How to Tell Whether Gravity Forms QR Code Fits Your Task

Task	Fit	What to Check First
Generate a QR code from a submitted form value	Yes, this is the core use case through :qr or [gpqr].	Where the code will appear: email, confirmation, PDF, or another output that supports merge tags.
Scan a code into a form field	Yes, built in for Single Line Text; other fields require a filter or snippet.	Camera access, HTTPS, mobile browser behavior, and how the theme handles the field area.
Check whether a ticket has already been used	Partially, because the QR code itself only passes along a value.	You need entry-status logic, record validation, or a separate tracking form.
Create a static QR code on a normal page	Usually overkill.	If the code is not tied to Gravity Forms, a dedicated tool is simpler.

What to Check Before Installing It on a WordPress Site

Before installation, make sure the site is ready specifically for a form with scanning and dynamic output. A QR code in an email or confirmation is usually straightforward, but a front-end scanner depends on the browser, camera, and JavaScript. If you skip that pre-check, the error will look like "the plugin doesn't work," even though the real cause may be the page, theme, cache, or device permissions.

Basic Site Readiness

Start with the basics: Gravity Forms should already be installed and working. The form where you plan to use the code should submit correctly even without QR features. Confirm that notifications are delivered, the confirmation appears, the form page is not breaking JavaScript, and the selected fields have clear names and IDs. That matters because Gravity Forms QR Code relies on existing fields and merge tags.

• Open the form in the editor and find the ID of the field that will serve as the QR code source.
• Make sure the selected field stores the exact value you want to encode, not just a decorative label.
• Confirm that the form page uses a secure connection, especially if camera-based scanning is required.
• Check that JavaScript optimization tools are not disabling critical Gravity Forms scripts on the form page.
• If the code will be sent by email, test the HTML email in advance with a test recipient.

Fields and Data You Should Not Choose Randomly

A QR code encodes text. That could be a number, URL, vCard string, coupon, token, or compound string. But you need to decide in advance what exactly will go inside it. For example, if you encode the attendee's name, you will get the name back at check-in, but you will not be able to reliably distinguish between two people with the same name. If you encode an entry ID or unique token, validation becomes more reliable, but those values should not be shown to users without context.

Dropdowns and radio buttons have a separate nuance: Gravity Forms may output the selected label instead of the underlying value. Gravity Wiz documentation notes that for choice fields with values enabled, you can use the :value modifier if you need to encode the stored value itself. That matters most for SKUs, internal codes, coupons, and external system integrations.

Checking the Camera and Scan Mode

Scanning a QR code in a form often looks like a simple button, but under the hood the browser must either open the camera or accept an image file containing the code. On mobile devices, the user will see a permission prompt. On desktop, drag-and-drop scanning from an image file may be more useful. So before launch, test the workflow on the actual devices where it will be used.

Required check: test not only the admin browser on your computer, but also the actual phone a user or staff member will use. Camera access issues tend to show up precisely where the form will be used in real life.

Installation and an Initial Sanity Check

If Gravity Forms QR Code is installed as part of Gravity Perks, it is usually managed through Spellbook and the Spellbook section in the WordPress admin. In other setups, the plugin can be installed the standard WordPress way through Plugins - Add New - Upload Plugin by uploading the ZIP file. In either case, you do not need to build custom authentication, connect third-party keys inside the form, or edit plugin files manually.

After activation, do not look for a separate global page where QR codes are configured for each form. Gravity Wiz documents a different model: generation happens through merge tags, while scanning is enabled in the settings of an existing field. So your first check should consist of two small tests: output a code from a field and enable the scanner on a Single Line Text field.

Mini Test for Code Generation

Create a test form with a Single Line Text field, for example "Ticket Number." In the confirmation or notification, insert that field's merge tag with the :qr modifier. If the field ID is 3, the example may look like this:

{Ticket Number:3:qr,size[300]}

Submit the form with a short test value. The expected outcome is that a QR code image appears in the selected location instead of plain text. If you are using a notification, check the email in both a mail client and webmail. If the code is needed in the confirmation, open the page after submission and scan the code with a standard phone scanner.

Mini Test for Scanning

In the same or a separate form, add a Single Line Text field. Open the field settings, go to the Perks tab, and enable Enable QR Code Scanner. After saving the form, open the preview or the page where the form is embedded. A scan button should appear next to the field. When clicked, the browser should request camera access or show the scanning interface.

At this stage, do not complicate the test with integrations or coupons. First scan a simple QR code with a short text value, make sure the value lands in the field, and only then move on to your real workflow. If a simple code does not scan, the issue is definitely not your coupon or ticket setup, but the scanner itself, the camera, JavaScript, or the form page.

Generating QR Codes with Merge Tags

Merge tags are the fastest way to output a QR code from a single form value. In standard Gravity Forms, a tag like {Email:5} inserts the field value. Gravity Forms QR Code adds the :qr modifier to that tag, so instead of text it outputs a code. This is especially convenient in notifications and confirmations, where the user immediately sees the result after submission.

Basic Syntax

The simplest form looks like this:

{Ticket ID:3:qr}

Here, Ticket ID is the field label, 3 is the field ID, and :qr tells the plugin to output a code. The label can stay for readability, but the important part is the ID. If you rename the field, the ID stays the same, so in working forms it is better to verify the ID in the Gravity Forms editor than copy an example from an old email.

Size, Color, and URL Output Instead of an Image

QR codes support size and color modifiers. Size is set with size, the background with bg_color, and the code color with fg_color. If you need the QR code file URL instead of an HTML image, use url. That is useful when inserting it manually into custom markup, a PDF template, or a download link.

{Ticket ID:3:qr,size[300]}
{Ticket ID:3:qr,fg_color[#111111],bg_color[#ffffff]}
{Ticket ID:3:qr,url,size[300]}

Do not overuse color. A QR code should stay high-contrast and easy for a camera to read. A light background with a dark code is the safest option. You can use brand colors, but reliable scanning matters more than matching the brand palette perfectly.

When You Need the Value Modifier

Choice fields have a common trap. The user sees one label in the interface, but the field may store a different value internally. For example, the label "VIP Ticket" might have the stored value vip_202. If the QR code needs to pass the internal code for validation, use the value-modifier approach documented by Gravity Wiz:

{Ticket Type:2:qr,value}

After setting this up, always submit a test entry and decode the QR code with a standard scanner app. It should contain the exact expected value, not the user-friendly label. This small check saves a lot of time later when the form is tied to a coupon, SKU, or external inventory system.

Compound Codes with the [gpqr] Shortcode

The :qr merge tag is convenient when you need a code from one field. But often you need to combine several values inside a QR code or add a fixed prefix. That is what the [gpqr] shortcode is for. It accepts text, merge tags, and attributes, then generates a code from the full internal string.

The practical benefit is simple: instead of encoding just "12345," you can encode a more meaningful string. For example, a ticket may include the event type, ticket number, and selected tier. An inventory code may include an SKU and a short command. A contact card may be built from several fields.

Multiple Fields in One QR Code

Example for a ticket:

[gpqr size="500"]Ticket Info: {Ticket ID:3} {Price:4.3}[/gpqr]

In a real project, the visible email copy can be written in any language, but the internal fragments inside the code itself are best kept short and stable. For example, if the code will be read by another form rather than a person, use a clean, easy-to-parse format like ticket_id=12345, sku=ABC-100, or checkin=entry_58. Do not pack large paragraphs into a QR code if they do not need to be scanned.

A URL Code That Opens a Form

If scanning the code should open a page, encode a full URL. For an event validation form, that might be a link to a check-in page with a token or ID parameter. The link itself should not expose unnecessary personal data. It is better to pass a token or technical identifier and then load the full details on the form side, if you have a confirmed data-transfer mechanism in place.

[gpqr]https://example.com/check-in/?ticket={Ticket ID:3}[/gpqr]

If you use it together with Easy Passthrough, Gravity Wiz documentation describes an option using {Easy Passthrough Token}. That token helps move data from one form to another without manually stuffing every parameter into the URL. There is a dedicated practical example later in this article showing how that pattern works for event registration.

A Code for Phone Actions or vCard Data

A QR code can contain more than a link. Gravity Wiz documentation includes an example of a phone action using tel:. For a contact card, you can build a vCard string from form fields, but here formatting discipline matters even more: an extra space, incorrect line, or wrong encoding can make the card unreadable in some apps.

[gpqr]tel:{Phone:1}[/gpqr]

If you work with multiple alphabets and languages, check encoding ahead of time. Gravity Wiz provides the gpqr_encoding filter, which lets you change the generation encoding, for example to UTF-8. Use it only if you have actually run into character corruption and know where to place a safe code snippet.

The Form Scanner: What the User Actually Sees

The scanner is useful when the form needs to accept a value from a QR code, barcode, or image. By default, Gravity Forms QR Code enables this mode for the Single Line Text field. Once the option is enabled in the field settings, the plugin adds a button that opens the scanning interface. When the code is recognized, the value is inserted into the form field.

This behavior is worth explaining to editors and staff ahead of time. They should not be looking for a separate scan page or a new menu item. Scanning happens directly inside the form the user is filling out. If you are running event check-in, the check-in page should publish the actual form, and the field with the scanner enabled should be clearly visible and labeled.

Setting Up a Single Line Text Field

1. Open the form in the Gravity Forms editor.
2. Add or select a Single Line Text field.
3. Give it a clear label, such as "Ticket Code" or "Product SKU."
4. Open the Perks tab in the field settings.
5. Enable Enable QR Code Scanner and save the form.
6. Open the preview and confirm that the scan button appears next to the field.

Why the Field Should Not Be Left Without Guidance

Users may not realize that the field accepts both manual entry and scanned input. Add a field description such as: "Scan the QR code from the ticket or enter the number manually." This not only improves usability, but also provides a fallback if the camera is temporarily unavailable. In real-world conditions, manual entry often keeps the workflow moving: a dead phone, poor lighting, a cracked screen, weak internet, or a browser camera restriction should not bring registration to a halt.

Scanning on Desktop

Gravity Wiz documentation notes that on desktop, the scanner field accepts drag-and-drop input from an image containing the QR code. That is convenient for administrators who receive the code as a file or screenshot. But it should not be your primary mode for high-volume event entry: for staff, it is usually easier to open the form on a phone or tablet with a camera than manually work through image files.

Quick takeaway: the scanner should be part of a clear form. A good field label, manual-entry fallback, and testing on a real device matter more than trying to hide the whole workflow behind a single icon.

Detailed Setup After Installation

Once the basic check passes, move on to the settings that determine the quality of the actual workflow: the data source, where the QR code is displayed, its size and format, scanner behavior, result verification, and compatibility with nearby plugins. There is no one universal value that works for every site. Tickets, inventory, coupons, and vCards all call for different choices.

Choose the Value Source

The first question is what exactly is being encoded. In practice, it is usually better to choose a value that is stable, does not expose unnecessary personal data, and works well for validation. For a ticket, that might be a Unique ID or Easy Passthrough Token. For inventory, an SKU or internal product code. For a coupon, a unique code created by separate logic. For a contact, a structured vCard string.

Do not encode the entire entry. The more data you put inside the QR code, the higher the chance of scan errors, the harder validation becomes, and the more privacy concerns you create. If people need to see full details, it is better to encode a link or identifier and show the full information only after opening the page or looking up the entry.

Decide Where the Code Will Be Displayed

Gravity Forms QR Code can output the code anywhere merge tags or shortcodes are supported. The most common locations are:

• Form confirmation. The user sees the QR code immediately after submission.
• Email notification. The code is sent to the user or administrator by email.
• PDF document. The code is added to a ticket, certificate, or document through a tool that supports merge tags or shortcodes.
• Submission preview. In a multi-page form, the code can appear before final submission if a compatible Preview Submission mechanism is in use.
• Public entry display. Through GravityView or similar tools, the code can appear as part of an entry card if the chosen output processes the necessary markup.

For emails, choose a size that displays well across different mail clients. For print and PDF, a larger code is usually needed. For a public page, make sure the code does not break the layout on mobile screens.

Set Size and Format Without Hurting Readability

For a standard QR code, the size parameter sets the width and height in pixels. Some non-QR formats use a relative sizefactor instead, because different barcodes have different standard proportions. If you use type[PDF417] or type[UPCA], do not expect size to behave the same way it does with a square QR code.

A medium size is often enough for email, but a printed ticket or badge needs a larger code. Do not judge size only by how it looks in the WordPress admin. Print a test ticket, scan it with the staff member's phone, and verify the outcome under the same lighting conditions where real validation will happen.

Colors and Contrast

The fg_color and bg_color settings let you customize the code and background colors. That can help with brand consistency, but QR codes have a physical limitation: the camera must be able to clearly distinguish the elements. Low contrast, busy backgrounds, and overly light code colors all reduce scan reliability. If your brand requires a colored code, keep the background clean and test on multiple devices.

Scanner and Additional Formats

By default, scanning is geared toward QR codes. If you need UPC, EAN, PDF417, or other formats, use the documented gpqr_scanner_config filter. That is already a technical JavaScript-level setting, so it is best applied only after the basic workflow is working. If the form works with a standard QR code, do not enable every format "just in case": the broader the list, the more workflows you need to test.

Validation After Saving Changes

After every important change, run a short validation loop:

1. Submit a test entry with a predictable value.
2. Open the place where the QR code is displayed and confirm that it appears.
3. Scan the code with a regular phone scanner and compare the decoded value with the expected one.
4. Scan that same code into a Gravity Forms form if your workflow includes reverse input.
5. Check the entry in the WordPress admin and make sure the value was stored in the correct field.

If the outcome does not match, roll back the last change instead of changing everything at once. For example, first return to standard colors, then to the default size, then to a simple one-field code instead of a compound [gpqr] build. That order makes it much easier to isolate the cause.

Practical Example: Event Ticket and Entry Validation

Let us walk through a real workflow that shows where Gravity Forms QR Code shines: a user registers for an event, receives an email with a QR code, and a staff member at the entrance scans the code and opens a validation form. This example can be adapted for a seminar, private club, access pass, seat reservation, or internal training session.

Goal

The goal is not just to produce a QR image, but to build a repeatable chain: the registration form creates an entry, the email contains the code, the code leads to a validation form, and the validation form receives the needed value without manual typing. In the simplest version, the code may contain the ticket number. In a more robust version described in Gravity Wiz documentation for the Easy Passthrough workflow, the code contains a link with {Easy Passthrough Token} so the validation form can pull data from the original entry.

Preparation

Before configuration, make sure you have two pages: a registration page and a validation page. The registration page contains the purchase or signup form. The validation page contains the staff-facing form. If you are using Easy Passthrough, first configure data transfer between the forms according to that perk's documentation: choose the source form, the target form, and map the fields.

For the unique value, you can use a dedicated field such as "Ticket ID." If the site already uses Gravity Forms Unique ID, that field works well as the QR code source. If Unique ID is not installed, you can use the entry ID or another stable identifier, but keep in mind that for public validation, it is better to avoid values that are easy to guess or fake.

Setup Steps

1. In the registration form, add a field that will store the ticket number or unique identifier.
2. Open the user notification and add explanatory text telling the user to present this QR code at the entrance.
3. Insert either a merge tag with :qr or the [gpqr] shortcode if you need to build a link.
4. If you use Easy Passthrough, build the validation-form link with the token.
5. In the validation form, add a Single Line Text field for the ticket code or token.
6. Enable Enable QR Code Scanner for that field under the Perks tab.
7. Publish the validation form on a page accessible to staff, and restrict access using standard site tools if needed.

Example notification code where the QR code points to the validation page and passes the Easy Passthrough token:

[gpqr size="400"]https://example.com/check-in/?ep_token={Easy Passthrough Token}[/gpqr]

If you are not using Easy Passthrough, you can pass a plain ticket number instead:

[gpqr size="400"]https://example.com/check-in/?ticket={Ticket ID:3}[/gpqr]

The second approach is simpler, but also easier to design badly. If the ticket number is supposed to pull personal details or entry status, you need separate validation logic. Do not treat the existence of a QR code itself as proof that the ticket is valid.

Verifying the Outcome

After setup, run a full dry test. Fill out the registration form with test data, receive the email, scan the QR code with a phone, and open the validation form. Make sure the target field is filled with the correct value, or that Easy Passthrough pulls the expected data. Then submit the validation form and open the entry in the WordPress admin.

Good outcome: the staff member scans the code, sees the key fields or the exact ticket identifier already populated, submits the validation form, and gets an entry that can be used to confirm the person actually checked in.

A Commonly Overlooked Detail

If the code points to a form by URL, check how caching behaves. The validation page should not serve the same cached output with someone else's parameters to every user. For forms that use personal parameters, it is better to exclude the validation page from aggressive caching or configure caching so query parameters are handled correctly. This matters even more if Easy Passthrough is also involved, because data transfer between forms may depend on the token, session, or cookie.

Workflows Where a QR Code Is More Useful Than a Regular Link

A QR code is not necessary in every project. It becomes valuable when a user or staff member physically moves information between devices, documents, and forms. Below are a few workflows where Gravity Forms QR Code does more than display a nice-looking code and actually reduces manual entry.

Coupon or Discount Code

Combined with Gravity Forms Coupons and Unique ID, you can generate a unique code, output it as a QR code in a notification, and then let the user scan it into a coupon field on another form. Gravity Wiz documentation describes this as a combination of QR Code, Coupons, and Unique ID. The practical benefit is simple: the user does not have to retype a long coupon manually and can just scan it.

Check two things carefully: code uniqueness and the point where the discount is applied. The QR code only carries the value. Limits, expiration, one-time use, and discount rules all need to be handled by the coupon mechanism itself. If the user can forward the email to someone else, the QR code can be forwarded too. So for serious discounts, add validation on the form side or within the ordering system.

Inventory and SKU

For internal inventory workflows, a QR code or UPC can help staff quickly populate an SKU into a restock, return, or stock-check form. Gravity Wiz describes a workflow for creating WooCommerce products through Gravity Forms, Unique ID, and Populate Anything. In practice, this is useful when you have a form that uses the code to pull the product name, current stock level, or other reference details.

Here it is especially important to decide which code is authoritative. If products already have a UPC, use the documented option to extend scanning to additional formats through gpqr_scanner_config. If you generate your own SKUs, keep the format stable and short. Do not change the SKU structure after launch without a migration plan, or old printed codes may start resolving to the wrong values.

vCard Contact Card

For a contact collection form, you can generate a vCard from the name, company, phone number, and email address. Gravity Wiz shows a setup where a hidden Paragraph field stores the vCard format and the QR code is generated from that value. This is useful for badges, business events, and internal directories. But it requires careful testing: different contact apps may interpret line breaks, encoding, and empty fields differently.

Accepting External Codes

If an organization already uses QR codes or barcodes, the form can act as the intake point for those values. For example, a staff member scans a code from a document, product, or access pass, and Gravity Forms stores the value in an entry. In that case, configuration starts not with generation but with the scanner: enable the field, verify the format of incoming data, add validation, and plan what should happen if the code is not recognized.

Useful Pairings with Other Gravity Forms Tools

Gravity Forms QR Code rarely stands alone. It becomes more powerful when paired with a tool that creates a unique value, passes data between forms, displays entries on the site, or generates PDFs. Below are practical combinations with clear roles that are supported by product documentation or the surrounding ecosystem.

Easy Passthrough for Moving Data Between Forms

Easy Passthrough helps transfer data from one form to another and supports tokens for cross-session handoff. Paired with QR codes, it is especially useful for check-in: the first form creates an entry, the notification contains a QR code linking to the second form, and the second form pulls values from the original entry. The role of QR Code is to make the link scannable. The role of Easy Passthrough is to securely move the data without forcing you to manually build a long string of URL parameters.

The setup order is important: first create the two forms and confirm data transfer works without the QR code. Then add the QR code containing the target-page link. After that, test the flow from a phone. If the transfer stops working, check the token, field mapping, cookies, and page caching. The rollback path is simple: restore a normal link in the notification and confirm the issue is not in the QR layer.

Unique ID for Tickets, Coupons, and Requests

Unique ID creates stable unique values inside a form. For QR codes, that makes it a natural source: it is better to encode an identifier you can verify than a name, email, or request description. This works well for tickets, certificate numbers, coupons, or internal passes. Validation is straightforward: submit several test entries and make sure each one gets its own code, and that each QR code decodes back to that exact identifier.

Populate Anything for Prefilling

Populate Anything helps fill form fields from existing data sources. In the QR Code documentation, there is a setup where Populate Anything together with Live Merge Tags helps generate a QR code on the page while the user is entering data. In the opposite direction, a scanned code can serve as the input value that the form uses to pull additional data. This is already a more advanced setup, so test it on a copy of the form first.

Gravity PDF and Printable Documents

Gravity PDF is useful when a QR code needs to appear in a ticket, certificate, access pass, or other document. Gravity Wiz documentation points out a specific nuance: in the GravityPDF header and footer, image height may be constrained, so for QR codes it can sometimes be better to manually build an img tag using the QR code URL and a max-height limit. That snippet should be tested in the PDF itself, not only in email.

<img src="/{:1:qr,url,size[200]}" style="max-height:200px">

This is a documentation example, but use it carefully: the field ID, size, and insertion point must match your own template. After the change, generate the PDF, print it, and test scanning from paper.

GravityView and Public Entry Display

If you need to display Gravity Forms entries on the front end, GravityView may be the right tool. Paired with QR codes, it is useful for a pass directory, participant list, internal database, or validation page. The role of GravityView is to display or filter entries on the site. The role of Gravity Forms QR Code is to turn the relevant entry value into a code or accept a scanned code through a form. Before launch, review access rules and do not publicly expose values that should remain internal.

Safe Enhancements and Careful Snippets

Gravity Forms QR Code includes documented hooks and ready-made snippets in the Gravity Wiz library. That is a good sign: behavior can be extended through supported integration points instead of editing plugin files. But code should be added only when it clearly improves a specific workflow. If the built-in scanner and generation already solve the task, there is no reason to add technical snippets "just in case."

Auto-Submitting a Form After a Successful Scan

At event check-in, staff may need to scan many codes in a row. In that case, it can be helpful for the form to submit automatically after a successful scan. Gravity Wiz publishes a snippet tied to the gpqr_on_scan_success event. You can use it through a safe custom JavaScript method, such as the developer's recommended snippet tool or a standard site-level mechanism you already use to manage custom scripts.

gform.addAction( 'gpqr_on_scan_success', function( decodedText, decodedResult, gpqr ) {
  gpqr.$input.parents( 'form' ).submit();
} );

Before enabling this behavior, make sure the form does not require extra confirmation, does not include required fields staff need to complete manually, and cannot create an invalid entry because of an accidental scan. Rollback is simple: disable the snippet and return to a manual submit button. For high-volume workflows, it is better to create a separate test page and run several codes through it in a row.

Scanning PDF417 and UPC-A

If the form needs to read more than QR codes, use the documented gpqr_scanner_config filter. Gravity Wiz provides an example that adds PDF_417 and UPC_A. This is relevant for access passes, inventory codes, and cards that already use a non-square barcode format.

window.gform.addFilter( 'gpqr_scanner_config', function( config, instance, formats ) {
  config['formatsToSupport'] = [ formats.QR_CODE, formats.PDF_417, formats.UPC_A ];
  return config;
} );

After enabling this, test each format separately. Do not assume UPC works just because QR scanning succeeds. If reading becomes unreliable, narrow the list of formats, improve lighting, check print quality, and return to the default mode if broader format support hurts the core workflow.

Encoding for Cyrillic Text

If a QR code contains Russian names, addresses, or a vCard with Cyrillic text and the characters become garbled after scanning, check the encoding. Gravity Wiz documentation includes the gpqr_encoding filter, which lets you return UTF-8. This is not something everyone needs to enable, but it is a safe option to test on a staging copy if the issue is specifically with character encoding.

add_filter( 'gpqr_encoding', function ( $encoding, $content, $form ) {
  return 'UTF-8';
}, 10, 3 );

Validation: create a QR code containing a Russian name and email, scan it with several devices, and compare the outcome. Rollback: remove the snippet and return to the default encoding. Do not use this snippet to fix problems that are actually caused by HTML markup, an incorrect shortcode, or the email client.

Validating the Workflow Before Launch

Even if the code appears in the email and the scanner opens the camera, that does not mean the workflow is ready. Validation should follow the full chain: input data, generation, delivery to the user, scanning, storage, repeat verification, and error handling. This matters especially for tickets, discounts, inventory operations, and contact cards.

Check the QR Code Contents

First decode the code with a regular scanner or camera app. Do not immediately send the data into the target form. Compare the text inside the QR code with the expected string. If it contains a link, open it in a private window or on another device. If it contains an ID, locate the matching entry. If it contains a vCard, make sure the contact imports correctly.

Check the Output Location

Email, confirmation pages, and PDFs can all handle the image differently. In email, the code may be blocked if images are disabled in the mail client. In a PDF, it may end up too small. On a confirmation page, it may be compressed by the theme or CSS. So the same QR code must be tested exactly where the user will see it.

Check the Scanning Form

Open the scanning form on a real device. Allow camera access, scan the code, confirm that the value lands in the intended field, and submit the form. After submission, open the entry in the WordPress admin. If auto-submit is enabled after scanning, make sure the form does not submit twice or create an empty entry.

Fallback Procedure

For public events or inventory workflows, you always need a fallback. In the field description, state that the value can be entered manually. Prepare a short instruction for staff: what to do if the camera does not open, the code is damaged, the email cannot be found, or the internet connection drops. That is not a sign of weak configuration. It is normal process protection.

Practical test: if a staff member can process one clean test ticket, one damaged code, and one manual entry without admin help, the workflow is in much better shape than if you only tested it in the dashboard.

How to Design the QR Code Contents

The most common strategic mistake is starting with the image instead of the data. A QR code looks like a design element, but for Gravity Forms QR Code it is first and foremost a text container. The string you put inside it determines how validation works, how secure the workflow is, how easy it is to support, and whether the code can be tied to another form. So before rolling it out at scale, define not just the output location but also the content format.

A good format answers three questions. First, can a person or system unambiguously identify what the code refers to? Second, does the code avoid exposing unnecessary data? Third, can you evolve the workflow later without reprinting all old codes? For a simple contact-card email, that may be a standard vCard. For a ticket, a short identifier or tokenized link is better. For inventory, an SKU, UPC, or another code already used in the tracking system makes more sense.

Identifier, Link, or Structured String

There are three practical content types. An identifier works well for validation inside the site: the code contains only a number or key, and the form or staff member looks up the entry. A link works well for moving between devices: the user scans the code and lands directly on the correct page. A structured string works well when the data needs to be meaningful immediately after scanning without contacting the site, such as for a vCard or a simple inventory code.

How to Choose QR Code Content for Different Tasks

Content Type	When to Use It	Risk	Validation
Short ID	Ticket, request, inventory action, internal entry validation.	Without separate validation logic, the ID may be guessed or reused.	After scanning, locate the entry and check its status.
URL	Open a validation form, profile page, or continuation form.	URL parameters may end up in browser history or be forwarded.	Open the link in a private window and confirm that it leads to the right form.
Transfer token	Easy Passthrough or another setup where the entry must be loaded without a long query string.	You need to configure token lifetime, caching, and form access correctly.	Test data transfer from another device and after refreshing the page.
vCard or formatted text	Contacts, badges, directories, and data exchange without opening the site.	Line breaks, Cyrillic text, and empty fields can hurt recognition.	Scan with multiple apps and compare the imported fields.

If you are unsure, start with a short ID and a separate validation page. That is easier to troubleshoot and safer to extend. Once the workflow is stable, you can add tokens, form-to-form data transfer, PDF documents, and auto-submit after scanning.

How Not to Overload the QR Code

A QR code can hold a lot of text, but that does not mean you should put the entire entry into it. The longer the content, the denser the code becomes, and the higher the requirements for size, contrast, and print quality. On a screen that may still work, but on a paper ticket, badge, or box label it quickly becomes risky.

A practical rule of thumb is this: if the code is for navigation or validation, it should contain a short key. The details belong in the Gravity Forms entry, a related table, a WooCommerce product, or another data source. If the code is for self-contained exchange, such as a vCard, keep the format strict and decide up front which fields are required. Do not add comments, marketing taglines, long product names, or internal admin notes to the QR code "just in case."

Versioning the Format Without Dates in the Code

Sometimes the workflow grows: at first the code contains only the ticket number, then later you add the ticket type, entry zone, or status. You do not need to include the launch date or plugin version inside the code. It is better to add a short format prefix that helps distinguish old and new codes without exposing extra details. For example, event-ticket:12345 is clearer than just 12345 if the site uses multiple code types.

This prefix is especially useful when one form scans different sources: tickets, coupons, inventory codes. After scanning, the staff member or the form logic can immediately tell what was read. If the prefix does not match the current form, you can show a clear message and offer a fallback entry path.

Email, PDF, and Print: How to Keep the Code Readable

Where the QR code appears has a major impact on the outcome. On a confirmation page, it is displayed in the browser immediately after submission. In email, it depends on the mail client. In a PDF, it depends on the document template and image constraints. On paper, it depends on the printer, size, contrast, and distance from the camera. So the same shortcode or merge tag cannot be considered validated until you test it on the final medium.

Email Notification

If the QR code is emailed to the user, place a short instruction next to it and include a fallback text identifier. For example: "Show this QR code at the entrance. If the camera cannot read it, provide your ticket number." This simple rule shortens lines at events and helps when the email client is temporarily not displaying images.

Do not place a QR code in an email without context. The user should understand why it is there and what will happen after it is scanned. If the code points to a validation form, do not show the full technical URL as the main element, but do include a clear fallback number. If the code contains a coupon, explain where to use it. If it contains a vCard, explain that scanning it lets the user save the contact.

What to Check in Email

• The message opens in a standard mail client without a broken layout.
• The QR code is not compressed to a size that makes scanning impossible.
• A human-readable number or link appears nearby if the workflow is critical.
• The code can be scanned from both a phone screen and a computer screen.
• If images are blocked, the user can still understand what to do next.

PDFs, Certificates, and Tickets

PDF documents are often printed, forwarded, and opened on many devices. That means a QR code in a PDF needs size headroom. If the code sits next to text, do not place it too close to the edge, a decorative border, or a patterned background. A QR code needs a clean quiet zone around it, or the camera may have trouble detecting its boundaries.

Gravity Wiz specifically documents a GravityPDF nuance: if the QR code in a header or footer looks wrong because of an image-height limit, you can output the QR code URL and build your own img tag with max-height. That is not magic and not a universal fix. It is a targeted way to control size inside the template. After making that change, test the PDF not only in the browser but in the generated document itself.

Print a Test Copy

For a ticket, badge, or sticker, a print test is mandatory. A QR code may look perfect on screen but become too small or lose contrast on paper. Print a single sample in the same format in which it will actually be used. Then scan it from a distance similar to the real staff workflow. If the camera has to be held very close and hunt for focus, the code is too small or too dense.

Public Page and WordPress Blocks

If the QR code appears on a public page, such as an entry card or customer account area, check responsiveness. The image should not overflow its container, overlap neighboring fields, or break the layout on mobile screens. If the code is inserted through a tool that processes shortcodes, make sure it does not escape HTML or replace the image with plain text.

For pages that include a scanning form, also check that optimization and caching tools do not defer the needed scripts until after the user has already clicked the scan button. If the scanner appears only after a second refresh or does not open in a private window, look for conflicts with JavaScript optimization, the theme, or the cache plugin.

Troubleshooting Common Problems

QR code problems often look similar at first: "it won't scan," "it doesn't show up," or "the value isn't inserted." But the causes are different. Below is symptom-based troubleshooting so you do not end up changing settings blindly.

The QR Code Does Not Appear in a Notification or Confirmation

Symptom: instead of a QR code, you see plain text, empty space, or the raw merge tag.

Possible cause: the merge tag is written incorrectly, the field has a different ID, the :qr modifier is placed in the wrong part of the tag, or the output location is not processing the required markup.

What to check: open the form editor, select the field, and confirm the ID. Insert a simple merge tag without extra colors or shortcodes. Test the on-page confirmation first, then the notification. If the confirmation works but the email does not, the issue is probably in the email output or client.

How to fix it: go back to the minimal version {Field:ID:qr}, then add size, url, and colors step by step. If you need the code in a third-party template, verify that it supports HTML images from merge tags.

The [gpqr] Shortcode Outputs the Wrong Link

Symptom: the QR code scans, but it opens the wrong URL or contains extra characters.

Possible cause: HTML tags, visual-editor line breaks, or an incorrect merge tag ended up between the opening and closing [gpqr]. Gravity Wiz documentation specifically recommends checking the raw HTML in text mode if the URL inside [gpqr] behaves unexpectedly.

What to check: switch the notification or confirmation editor to text mode and see whether extra tags were inserted inside the shortcode. Copy the decoded QR code output into a plain text editor and compare it with the expected URL.

How to fix it: remove the extra markup from inside [gpqr], rebuild the URL, and test again. If the editor keeps inserting HTML, store the complex string in a separate field or simplify the email markup.

The Scanner Does Not Appear Next to the Field

Symptom: the field is on the form, but there is no scan button.

Possible cause: the option is enabled on the wrong field, an unsupported field type is selected, the form was not resaved, page cache is serving an old version, or another plugin is breaking scripts in the editor or front end.

What to check: make sure the field is Single Line Text. Open that field's Perks tab and confirm Enable QR Code Scanner. Clear the page cache and open the form in a private window.

How to fix it: first get it working on Single Line Text. If you need Paragraph Text or Email, use the documented Gravity Wiz filters or snippets and test them separately. If the button appears after cache is disabled, exclude the form page from optimization.

The Browser Keeps Asking for Camera Permission

Symptom: every time the scanner opens, the user is asked again for camera access.

Possible cause: permission behavior depends on the browser, device, and site settings. Gravity Wiz documentation specifically notes that camera-permission handling differs across devices and apps.

What to check: test the same site in another browser and on another device. Make sure the page loads over a secure connection and that the user has not blocked the camera for the domain.

How to fix it: give users a short instruction on how to allow camera access for the site. For staff check-in devices, it is better to prepare devices in advance instead of relying on personal phones with unknown settings.

The Code Is Hard to Read from Paper or a Screen

Symptom: the code scans sometimes but not reliably, especially on printouts, badges, or older phones.

Possible cause: the size is too small, contrast is too weak, the background is too colorful, the print quality is poor, the screen is damaged, or the QR content is too long.

What to check: increase the size with size, return to a dark code on a white background, shorten the content, and print a test copy. Check the same code on several devices.

How to fix it: encode a short ID or URL instead of a large block of data. For a printed ticket, place a human-readable number next to it so staff can type it manually if needed.

The QR Code Looks Wrong in a PDF

Symptom: in the PDF, the code is cropped, too short, distorted, or hard to scan.

Possible cause: the PDF template is limiting image height, especially in the header or footer. Gravity Wiz points to a GravityPDF constraint and suggests manually outputting an img tag using the QR code URL with max-height.

What to check: compare the code in a normal confirmation with the one in the PDF. If it looks fine in the confirmation but distorted in the PDF, the problem is in the PDF template, not the QR generation.

How to fix it: use QR code URL output and a manual img tag with a height limit, then test the PDF on screen and on paper. If the template is heavily styled, move the code from the header or footer into the main document area.

Cyrillic Text or vCard Data Reads Incorrectly

Symptom: after scanning, Russian characters turn into the wrong symbols or the contact imports only partially.

Possible cause: encoding, line breaks, empty fields, or an invalid vCard format. Gravity Wiz documentation includes the gpqr_encoding filter for encoding issues.

What to check: first create a QR code with a short Russian string, then one with a vCard. If the simple string is corrupted, check encoding. If the simple string reads correctly but the vCard does not, inspect the vCard structure.

How to fix it: apply UTF-8 through the filter only after confirming an encoding problem. For vCards, remove optional fields and test the format in several contact apps.

Limits, Security, and Privacy

A QR code may look convenient, but it does not make data secure on its own. Anyone who can see the code can scan it or forward the image to someone else. That is why real workflows need to separate two jobs: passing a value and validating the right to take an action. Gravity Forms QR Code handles the first. The second needs to be implemented through form logic, access control, unique values, entry statuses, or an external system.

Do Not Encode Unnecessary Personal Data

For a ticket, it is better to encode a token or identifier rather than a full name, phone number, email address, and the full set of fields. For a vCard, personal data is the point of the code, but the user should understand what they are sharing. For internal inventory workflows, do not place commercially sensitive information into the code if an SKU or internal identifier is enough.

Do Not Treat a QR Code as Protection Against Reuse

If the same QR code can be copied, photographed, and forwarded, it can also be reused. To prevent duplicate ticket entry, you need status logic: for example, once scanned, the entry receives a "used" marker, and the next attempt triggers a warning. That logic should not be invented inside the QR code itself. It needs to be built into the validation form, Gravity Forms entries, conditional logic, an integration, or a separate process.

Caching and Parameterized Pages

If the QR code points to a URL with a parameter, caching must either account for that parameter or skip caching the validation page entirely. Otherwise one user may see another person's output, or the form may fail to receive fresh data. Be especially careful with aggressive JavaScript optimization and script combining on pages that use the scanner.

Staff Access

An event or inventory validation form does not always need to be public. If it displays personal data or changes an entry status, restrict access through standard WordPress tools, membership plugins, or a dedicated staff-only page. At the same time, keep in mind that the ability to scan a code should not automatically grant permission to view the full entry.

Questions to Resolve Before Launch

Why do I not see a separate QR Code field in the form editor?

That is normal for Gravity Forms QR Code. The developer chose to integrate with existing Gravity Forms mechanisms: QR codes are generated through the :qr modifier and the [gpqr] shortcode, while scanning is enabled on an existing Single Line Text field through the Perks tab.

Can I scan a code into a field other than Single Line Text?

By default, the scanner is designed for Single Line Text. For other field types, Gravity Wiz documentation provides filters and snippets, including examples for Paragraph Text and Email. Use them only after the basic Single Line Text test works, so you do not confuse a field-type issue with a scanner issue.

What is better to encode: an email, an entry ID, or a link?

For validation and tracking, it is usually better to encode an ID, token, or short link rather than personal data. An email is human-friendly, but worse for privacy and uniqueness. A link is useful when scanning should open a specific form or page. The right choice depends on what needs to happen after the scan.

Can I make a branded QR code with custom colors and a logo?

Colors are available through modifiers, and deeper styling is possible through documented file-generation filters. But test readability first. A logo inside the QR code requires a higher level of error correction and careful testing, or the visual styling may reduce reliability.

Why is the QR code in the email visible to some recipients but not others?

Email clients handle images differently. Some block external images until the user allows them, while others change sizing or styling. Test the email in several clients and place a regular text link or number next to the QR code as a fallback.

Will the plugin affect site speed?

Normal QR generation in a notification or confirmation should not create heavy load by itself, but the real outcome depends on how many codes are being generated, where they are displayed, caching, PDF generation, and other plugins. On pages that use the scanner, JavaScript and camera access matter as well. Test the form page before and after enabling the scanner.

Can I use Gravity Forms QR Code for ticket validation without additional logic?

You can pass a ticket number or a link, but that is not full protection against duplicate entry. For ticket validation, plan the entry status logic, staff permissions, manual-entry fallback, and the rule for what happens on a repeat scan. The QR code transfers a value. It does not replace business logic.

When Gravity Forms QR Code Is the Right Choice

Gravity Forms QR Code is worth using when your workflow already runs through Gravity Forms and you need to connect a form with a physical or cross-device action: send a ticket, validate an attendee, pass along a coupon, scan an SKU, display a code in a PDF, or accept an external QR code into an entry. The plugin's strength is that it works through familiar Gravity Forms building blocks rather than a separate interface you have to learn from scratch.

Before launch, validate three things: what exactly is being encoded, where the user will see the code, and how you will prove that the scan led to the correct entry. If those three answers are clear, move on to testing on a copy of the form, then on real devices, and only after that deploy the workflow to the live page.

If you need a dynamic code built from form data, a scanner inside a field, and clear integration with confirmations, notifications, and related Gravity Forms tools, then after confirming compatibility you can get the Gravity Forms QR Code file and build your first working workflow on a test form. Start with one simple field and one QR code, then add Easy Passthrough, PDF output, coupons, additional formats, and automation once the basics are solid.