The honest answer most QR posts skip
You have a thing — an image, a video, a PDF, an email address, a Wi-Fi password, a website URL — and you want a QR for it. Every blog post you find sells a different tool per content type, as if the QR pattern itself changes when the content does.
It does not. A QR code is a barcode that holds a small payload, specified by ISO/IEC 18004 — the international standard that defines QR encoding. In real-world use that payload is one of two things: a URL the phone opens after the scan, or a short string the phone interprets directly (text, mailto:, a vCard, a Wi-Fi credential). That is the entire universe. There is no special "image QR" or "video QR" technology — those are URL QRs pointing at hosted media (see the QR code Wikipedia overview for the full payload-format list).
The distinction that actually matters: can the content fit inside the QR, or does it have to live on the internet and the QR points at it? Plain text, email links, contact cards, and Wi-Fi credentials are small enough to encode directly. Images, video, and PDFs are not — the QR holds the link, not the file. Getting this right is the whole post. The next 3,000 words are the per-content-type URL patterns, the workflow, and the failure modes most posts will not name.
The universal workflow — works for every content type
The steps are the same for every QR. The only thing that changes is what you paste in step two.
1. Identify what the QR will encode. Either a URL (where the file or page lives) or a short string (mailto:, vCard, Wi-Fi, plain text). The reference table near the end of this post maps every content type to its pattern.
2. Get the exact URL or string. For hosted content (images, video, PDFs), this is the public share link from your host. For directly-encoded content (text, email, contacts, Wi-Fi), this is the literal string you want the phone to read.
3. Paste it into a [URL QR generator](/qr-codes/url). Choose static (free, permanent, the destination is baked into the pixels) or dynamic (paid, editable, the QR holds a short redirect URL you can repoint later).
4. Customize lightly. Colors, a logo, the right size for your print medium. Keep contrast high — light background, dark foreground.
5. Scan-test. Open the camera app on a real phone. Confirm the QR opens what you expect. For hosted content, test in an incognito browser too — sharing permissions break more QRs than the QR itself does.
6. Print or publish. Use SVG for print, PNG for screen.
The whole workflow is under two minutes per code once you have the source URL or string. Most of this post is about getting that source right.
QR codes for URLs — the universal default
A URL QR is the base case. The phone scans it, opens the camera notification, taps the URL, and lands on whatever page you encoded. Every other content type below is either this with a different destination, or a directly-encoded string instead of a URL.
How you make one: open a URL QR generator, paste the full URL including https://, choose static or dynamic, generate, download. Done.
The one tradeoff worth knowing: longer URLs produce denser QR codes — more pixel modules packed into the same physical square. A 30-character URL fits comfortably in a Version 3 QR (29×29 modules). A 200-character URL with UTM parameters needs Version 8 (49×49 modules) or higher, which means each pixel module gets smaller at the same printed size and degraded scanners (greasy phone cameras, low light, glossy paper) miss the scan. For print, a short URL is the cheapest reliability upgrade.
If your destination URL is long because of UTM parameters or session IDs, two options. Use a dynamic code — the QR encodes a short redirect URL (ezqr.com/r/abc123) and the long destination lives on the redirect target. Or shorten the URL with a link shortener and encode the short link as a static QR. Either way the printed pixel density drops and scan reliability climbs.
Use cases that just work: storefront window decals to your homepage, business cards to your portfolio, conference badges to your LinkedIn, restaurant menus to an online ordering page, real-estate signs to a listing page. URL QRs are 80% of all QR codes in the wild, and a static URL QR is free on EZQR.
QR codes for images and photos — the QR holds the link, not the image
No QR code can hold an image file. JPEGs and PNGs run from a few hundred kilobytes to several megabytes; a QR code maxes out at 4,296 alphanumeric characters or about 2,953 bytes of raw data (Version 40 at the lowest error correction level). Even a thumbnail is 30-100× too big.
The real workflow: host the image somewhere with a public URL, then encode that URL as a standard URL QR.
Hosting options that work without surprises:
- Google Photos shared album. Open Google Photos, create an album, add the image, click Share, set "Link sharing" to on. Copy the resulting
photos.app.goo.gl/...URL. Good for photo-sharing scenarios — wedding photos, event galleries, family albums. - Imgur direct link. Upload to Imgur, right-click the image on the upload page, "Copy image address." You want the direct-link
i.imgur.com/ABC.jpgURL, not the page URL. Loads instantly on any phone. - Your own site. If the image already lives on your website, just copy the image URL (right-click → "Copy image address"). Most durable option because you control the host.
- Cloud storage. Dropbox, OneDrive, iCloud Drive all produce shareable image URLs. Same sharing-permission gotcha as PDFs (next section) — test in incognito.
Once you have a public URL, paste it into a URL QR generator. The scanner opens the image directly in their phone browser. They can pinch-zoom, save it to camera roll, or share it onward.
Photo-sharing-specific use cases: wedding QR cards that point at a shared Google Photos album so guests can see the gallery the next day. Real-estate yard signs with a QR to a property photo gallery. Restaurant menu inserts with QRs to dish photos. Product packaging with a QR to a high-res lifestyle image. Same workflow every time — the trick is choosing a host whose share link does not break in six months.
QR codes for video — same rule, bigger files
Video is even more lopsided than images. A one-minute 1080p video runs 50-200 MB; the QR specification's ceiling is under 3 KB. You will not find a QR that holds a video file, and you will not find a workaround. The QR points at a hosted video.
The hosts that just work:
- YouTube. Upload (public or unlisted), copy the share URL (
youtu.be/XYZor the fullyoutube.com/watch?v=XYZ), paste into a URL QR generator. The scanner opens it in the YouTube app or browser. Useyoutu.be/XYZ?t=42to deep-link to a specific timestamp. - Vimeo. Same workflow. Vimeo's privacy settings include "Hide from Vimeo" which still allows direct-link viewing — useful for client work you do not want on Google.
- Self-hosted. Upload the video to your site (or a CDN like Cloudinary, Mux, Bunny), copy the playback URL. More control, no third-party logo. Higher monthly cost if scan volume is real.
- TikTok or Instagram. Copy the share link from the video. Works for organic content but adds an app-handoff step on iOS that loses some viewers.
For product packaging, event signage, or print ads that point at a tutorial or hype video, YouTube is usually the right answer because the playback experience is universal. For training material that should not be public, Vimeo with privacy controls beats anything else. Detailed teardown of video-specific QR workflows in our video QR code generator guide, including which scenarios actually justify a paid video-QR tool versus a free URL QR.
One dynamic-code argument that does land for video: if you might want to swap the video later (a new product launch, a corrected tutorial), use a dynamic code so you can repoint the QR without reprinting. For a one-off tutorial video that will live at the same URL forever, static is fine.
QR codes for plain text — encoded directly, no internet required
Plain text is the simplest case after URLs. The QR holds the literal text; the scanner reads it and shows it on screen. No host, no internet at scan time, no failure mode beyond the QR being unreadable.
How to make one: open a text QR generator, type or paste the text, generate. The QR encodes the exact characters you typed.
The length limit is the only real constraint. At Version 40 with the lowest error correction level (L), a QR holds 4,296 alphanumeric characters or 2,953 raw bytes. In practice you want shorter — denser QR codes get harder to scan on bad cameras, low light, or curved surfaces. A 50-100 character text limit keeps the QR readable from a typical phone scan distance with a mid-range camera.
When plain-text QRs actually earn their keep:
- Offline labels. Warehouse bin labels with the part number encoded directly. Scanners work even when Wi-Fi is dead.
- Equipment serial numbers. A QR on a piece of gear that holds the serial number — a technician reads it without typing.
- Simple instructions. A QR on a packaging insert with a 200-character setup note. No website needed.
- Coupon codes. A QR that decodes to a short alphanumeric code the customer enters on your website. Cleaner than asking them to type it.
- Conference name tags. A QR with the attendee's name and company encoded as text. Anyone with a camera can read it without an app or signup.
The contrarian take: most use cases people reach for "text QR" actually want a URL QR. If you want the scanner to land on a page, encode the URL. Use plain text only when the value is the text itself and a website would just be friction.
QR codes for email — the mailto: URI, encoded directly
An email QR opens the scanner's default mail app with the recipient, subject, and body pre-filled. The scanner reviews, taps send. Two taps from camera to outgoing email.
The encoded string is a mailto: URI, RFC 6068. The format:
mailto:[email protected]?subject=Question%20about%20your%20product&body=Hi%2C%0A%0AI%20saw%20your%20QR%20code%20and...
The parameters: the email address is the path, subject and body are URL-encoded query parameters. Spaces become %20, line breaks become %0A, and special characters get the URL-encoding treatment. Most email QR generators handle the encoding for you — you type the recipient, subject, and body into a form and the tool produces the mailto: string.
Like plain text, mailto: QRs are encoded directly into the pixels. No internet required at scan time. The scanner's phone just opens its default mail app with the pre-filled draft. Works offline.
Real use cases: customer service stickers with a "Email support" QR that pre-fills the subject line with your support address and a generic "I need help with..." starter. Lost-pet tags with a QR to email the owner with a pre-filled "I found your pet" subject. Real-estate flyers with a QR to email the listing agent. Trade-show booths with a QR that opens a "Tell me more about [product]" email. Every one of these gets a higher response rate than a printed email address because there is no typing.
Dedicated tool: our email QR generator builds the mailto: URI for you. Or roll your own with any URL QR generator — just paste the full mailto:... string and it encodes as a static QR. Either way, the QR works offline because the mailto: URI lives entirely in the pixels.
QR codes for PDFs and documents — the sharing-permission trap
PDFs follow the same rule as images and video: too big for the QR itself, so the QR holds a link to where the PDF is hosted.
Hosts that work without drama:
- Your own website. Upload the PDF to your site (typically
/wp-content/uploads/...on WordPress or/files/...on a static site), copy the direct URL. The most durable option because the URL is under your control. - Google Drive. Upload, right-click → Share, set "General access" to "Anyone with the link — Viewer," copy the link. Append
/previewinstead of/viewfor a cleaner mobile reader without the Drive interface. - Dropbox. Right-click the file → "Share" → "Create link." Copy the resulting
dropbox.com/s/...URL. Append?dl=1if you want the PDF to download instead of preview. - Cloudinary or S3. Upload, get the public asset URL. No sharing dialog to misconfigure.
The sharing-permission gotcha is brutal. Google Drive defaults to "Restricted" — only people you explicitly added can open the file. Your browser opens it fine because you are signed in; outside scanners hit a sign-in wall and bounce. Same story for Dropbox shared links that default to "people in your team only," and OneDrive links that default to "people in your organization." Test every PDF QR in an incognito window before you print. If incognito opens the PDF without prompting for sign-in, the QR works for the public. If it asks you to sign in, you have a sharing problem, not a QR problem.
What works as a default workflow: upload the PDF to Google Drive, set sharing to "Anyone with the link — Viewer," swap /view for /preview in the URL, encode the preview URL as a static QR via our PDF QR generator. Test in incognito. Print. The PDF reader experience on iOS and Android handles the rest.
Use cases: trade-show booth handouts with QR to a product spec sheet. Real-estate sign riders with a QR to the property fact sheet. Trail markers with a QR to a trail map PDF. Conference name badges with a QR to the agenda. Restaurant menus with a QR to the allergen-detail PDF. Hospital intake forms with a QR to the post-visit care sheet. Every one of these breaks if sharing permissions are wrong — the QR is the easy part.
QR codes for vCards — contact info encoded directly
A vCard QR holds your full contact card (name, phone, email, company, title, website, address) as a single string. The scanner reads it, the phone offers "Add to contacts," and your card is saved with one tap. Works offline.
The encoded string is a vCard 3.0 or 4.0 record:
BEGIN:VCARD\nVERSION:3.0\nFN:Jane Doe\nORG:Acme Co\nTITLE:Engineer\nTEL:+15551234567\nEMAIL:[email protected]\nURL:https://acme.com\nEND:VCARD
Most vCard QR generators build this string from form fields — you fill in name, phone, email, and the tool emits the full vCard record. Our vCard QR generator handles the format and outputs a static QR.
The length tradeoff matters here. A full vCard with name, two phones, two emails, address, title, company, and website runs 250-400 characters — well within the QR capacity, but dense enough that printed size matters. Below about 1.5 inches square on print, dense vCards get unreliable on mid-range phone cameras. The fix is either a larger printed size or a leaner vCard (drop the address line, keep one phone and one email).
Use cases: business cards (the original killer app), conference badges, trade-show booth signage where you want attendees to save the rep's contact in one tap, real-estate yard signs with the agent's vCard. The offline-encoding property is the real value — the contact saves even if cellular and Wi-Fi are dead.
The MECARD: format is a shorter alternative for the same job and predates vCards on QRs by a few years. It encodes the same fields in a denser string but is less universally parsed; vCard 3.0 is the safer default in 2026.
QR codes for Wi-Fi — the credential string, encoded directly
A Wi-Fi QR encodes the network name, password, and encryption type as a single string. The scanner reads it, the phone asks "Join this network?", they tap yes, they are on Wi-Fi. No typing.
The format is a de-facto standard popularized by Android and supported by iOS since iOS 11 — same encoding family covered in the QR code spec overview:
WIFI:S:NetworkName;T:WPA;P:YourPassword;H:false;;
The fields: S is the SSID (network name), T is the encryption type (WPA, WPA2, WEP, or nopass for open networks), P is the password, and H:true if the SSID is hidden. The two trailing semicolons terminate the string.
Our Wi-Fi QR generator takes the SSID, encryption type, and password as form fields and emits the encoded string. The output is a static QR — the credentials live in the pixels.
Use cases: café and coworking-space window decals so guests can join without asking. AirBnB house manuals where the QR replaces the handwritten password on the fridge. Conference signage so attendees join the venue Wi-Fi without queueing at the help desk. Office reception areas for guest Wi-Fi. Home routers where the homeowner prints a tiny QR and tapes it to the underside of the router.
The security caveat worth naming: a printed Wi-Fi QR is the password in plain sight. Anyone with a phone can scan and join. For a public guest network this is fine. For a corporate network, do not put the production Wi-Fi password on a printed QR. Create a guest VLAN with a separate password and QR-encode that.
Reference table — content type to URL pattern or encoding
Pin this for the cluster. Each row maps a content type to the pattern you encode, whether the QR holds the content directly or points at a hosted URL, and what kind of QR makes sense as a default.
| Content type | Pattern or URL | Direct or hosted | Default QR type | Notes |
|---|---|---|---|---|
| Website URL | https://example.com/page | Direct (URL in pixels) | Static | The base case. Shorter URLs scan more reliably. |
| Image / photo | https://i.imgur.com/ABC.jpg or your CDN URL | Hosted (QR points at file) | Static | Image must be on a public host. Google Photos shared album works for personal shares. |
| Video | https://youtu.be/XYZ or self-hosted MP4 URL | Hosted (QR points at video) | Static or dynamic | YouTube is the universal default. Dynamic if you might swap the video. |
| Plain text | Up to 4,296 alphanumeric characters | Direct (text in pixels) | Static | Works offline. Keep under 100 chars for print reliability. |
| Email (mailto:) | mailto:[email protected]?subject=...&body=... | Direct (mailto: in pixels) | Static | Opens the default mail app pre-filled. Works offline. |
| PDF / document | https://example.com/file.pdf or Drive preview URL | Hosted (QR points at file) | Static | Sharing permissions are the #1 failure mode. Test in incognito. |
| vCard contact | BEGIN:VCARD\n...END:VCARD | Direct (vCard in pixels) | Static | Saves offline. Keep fields lean for smaller printed sizes. |
| Wi-Fi credential | WIFI:S:SSID;T:WPA;P:password;; | Direct (credentials in pixels) | Static | Password is in plain sight on the print. Use for guest Wi-Fi only. |
| Multi-destination | ezqr.com/r/abc → picks URL by device or geo | Hosted (QR points at router) | Dynamic | For app-store deeplinks or per-region landing pages. See multi-URL. |
| Editable destination | ezqr.com/r/abc → repointable from dashboard | Hosted (QR points at redirect) | Dynamic | Use when the destination might change after printing. |
Static vs dynamic — which to choose per content type
Every QR generator post you read pushes dynamic codes harder than it should because dynamic codes are what the vendor charges for. Here is the version with the marketing pressure off.
Use static when:
- The destination URL is permanent (your homepage, a published PDF on your site, a YouTube video that will not move).
- The content is encoded directly (text, mailto:, vCard, Wi-Fi) — these are inherently static; there is no redirect to manage.
- You do not need scan analytics.
- You do not want to be on a subscription for a QR that should just keep working.
Use dynamic when:
- The destination might change after print. Event rotations, A/B tests, multi-location campaigns where corporate repoints all 47 location-specific QRs in one click.
- You need per-code scan analytics — counts, timestamps, rough geography, device type.
- The destination URL is long (UTM parameters, session IDs) and you want a denser pixel pattern; dynamic encodes a short redirect URL.
- You need device-aware routing (App Store on iOS, Google Play on Android) — that is a multi-URL QR, which is a flavor of dynamic. See our multi-URL QR generator.
The content-type-to-default mapping: URL, image, video, PDF default to static unless you have a specific reason to go dynamic. Text, email, vCard, and Wi-Fi are always static because they encode the content directly — there is no URL to redirect. Dynamic earns its monthly cost only when the editability or analytics genuinely save you a reprint or inform a real decision. Full teardown in static vs dynamic QR codes.
The cancellation timebomb — why your generator choice matters years later
A QR code printed on a flyer outlives the subscription that made it. This is the failure mode most marketing teams do not think about until a year later, when the printed code stops working.
A static QR encodes the destination directly into the pixels. The code works forever because the destination is the QR. The generator could shut down tomorrow and the code keeps resolving — there is no server in the loop. That is true for every directly-encoded content type in this post (URL, text, mailto:, vCard, Wi-Fi) when generated as static.
A dynamic QR encodes a short redirect URL pointing at the vendor's servers. If the vendor turns off the redirect, the code dies. QR Tiger pauses dynamic codes immediately on subscription lapse and deletes them at 30 days. Beaconstac behaves similarly. EZQR is built so codes survive cancellation — full vendor-by-vendor behavior in permanent QR code generator 2026.
Practical rule: for permanent destinations and directly-encoded content, use static and stop thinking about this. For destinations that need to change after print, use a dynamic code from a vendor that does not hold your printed materials hostage. Print is forever; subscriptions are not.
Pre-print execution checklist
Run every QR through this list before sending anything to print. Catching one bad URL on screen costs nothing; catching it after 5,000 flyers is the whole campaign.
Tips
- URL or string audit — paste the destination into your address bar (not the QR) and confirm the right thing loads or the right text appears.
- Incognito test — for hosted content (images, video, PDFs), open the URL in an incognito window. Confirm it loads without a sign-in wall. This catches sharing-permission errors that pass when you are signed in.
- Mobile test — open the destination on an actual phone. PDFs and Google Slides render differently on mobile than desktop; vCards and Wi-Fi QRs prompt differently across iOS and Android.
- UTM tag (for URL QRs) — append `?utm_source=qr&utm_medium=print&utm_campaign=...` before generating if you want to track scans in GA4. Once printed you cannot add UTM later.
- Scan test — generate the QR, scan it with the camera app on an actual phone (iPhone Camera, Android Camera). Confirm it opens the right URL or shows the right content on the first try.
- Print proof — print one copy at production size on the production substrate. Re-scan from the printed copy at typical viewing distance. Glossy paper, low light, and small print sizes are where QRs fail; see [error correction level](/blog/qr-code-error-correction-levels) for the safety margin to add.
- Permanence check — if you used a dynamic code, verify the destination URL in your generator dashboard matches what you tested. If you used static, the destination is the QR and you are done.
When to use EZQR vs alternatives
For static QRs across every content type in this post — URL, image, video, PDF, text, email, vCard, Wi-Fi — the EZQR generators are free, no signup, support custom colors and logos, and export PNG and SVG. Sibling pillar coverage in our Google QR code guide, Microsoft QR code guide, and the best QR code generators of 2026 comparison.
For dynamic codes — editable destinations, scan analytics, multi-URL routing — EZQR Lite at $5/mo (monthly billing) handles single-operator use. Max at $20/mo adds CSV bulk import and API access for ops teams generating hundreds of unique codes. Codes survive cancellation by design.
Alternatives we benchmarked: QR Tiger Premium at $37/mo (annual required) is the mature enterprise pick if you need SOC 2 reports and a public API, with annual lock-in and codes that deactivate on cancellation. Beaconstac and Uniqode have similar cancellation behavior at similar price points. For the content-type how-tos in this post, those features are overkill — a free static QR from any honest generator does the job.