Put the guidance into practice: open the related free tool. Examples use stated inputs and are not measured performance claims.
| Choice | Tidy QR output | Useful distinction |
|---|---|---|
| vCard | vCard 4.0 record | A standards-defined contact format |
| MeCard | Compact MeCard-style record | A simpler contact convention |
| Website URL | Direct profile-page link | Details can change behind a stable page |
| Plain text | Literal text | Does not promise contact import |
Choose between storing details and linking to them
A contact code can carry the name, phone number, email and organization directly. That makes those details available after decoding without fetching a profile page. It also means the information remains fixed in the printed pattern.
A URL to a profile page works differently. You can update the page while keeping its address stable. The visitor needs to reach that page, and any contact download or save action depends on how the page is built. Choose based on how often the details change and how the visitor should use them.
Do not encode unnecessary personal information merely because fields are available. A public business card can be photographed and shared. Only include details you intend to distribute to that audience.
vCard has a defined record structure
RFC 6350 defines vCard 4.0, including property syntax and text handling. Tidy QR builds a record using that version rather than concatenating arbitrary labels. It escapes characters that have structural meaning and uses line endings appropriate to the format.
Long content lines require folding under the specification's rules. That is a byte-oriented formatting concern, not a reason to manually insert random line breaks into a name. The generator handles the record structure while the user supplies the contact values.
Receiving applications may differ in their support for vCard versions and properties. A compliant record is a good starting point, but the practical question is whether the intended scanner offers a useful import and preserves the relevant fields.
MeCard is a different convention
MeCard uses a compact field notation documented in the ZXing content guide. It can be useful for common contact details, but it should not be described as merely a smaller vCard file. Its syntax and supported fields differ.
Tidy QR provides a separate MeCard option so the selected format is explicit. The same contact can produce a different payload string and potentially a different QR density depending on the format and included values.
Test whichever choice best matches the receiving devices. Avoid asserting that one convention is universally superior based on a single phone. The scanner and contact application together determine the final action.
A worked business-card proof
Create an illustrative contact with a name, organization, phone number and email address. Confirm that each field contains the intended value, then generate the contact code. Read its full payload in the local reader before adding it to the business-card layout.
Scan the finished proof with a phone that does not already have the contact saved. Review the proposed record before importing it. Check the name order, phone number, email and organization individually; a contact-import screen appearing is not enough to prove that every field survived correctly.
If the record is displayed only as text, try the alternate supported format or a profile-page URL. Provide a readable email or phone number on the card so the QR route is an option rather than the only way to reach the person.
International characters affect bytes and testing
UTF-8 represents text as bytes, and a visible character is not always a single byte. Names with accents or other writing systems can therefore affect the encoded length differently from an equally long ASCII string. The generator's selected version reflects the actual encoded payload.
Keep names in their correct form rather than removing meaningful characters simply to make the grid smaller. If density becomes a problem, remove unnecessary optional content or use a stable profile page instead of reducing legibility in the contact details.
Test the import with the actual characters that will be printed. A test using a short placeholder name does not validate a later record with different punctuation, line lengths and text encoding.
Phone and email fields need content review
A structurally valid phone field can still contain the wrong number. Use an appropriate international format when distributing cards across regions, and review the value with the owner. The generator cannot infer which contact route is correct for the person.
Likewise, an email address that passes basic syntax checks is not proof that the mailbox exists or belongs to the intended recipient. No test message is required merely to create the code; confirm the address through the organization's normal source of truth.
Keep labels clear in the surrounding design. If the code saves a contact, say so. A visitor should not have to scan an unexplained square to discover whether it opens a website, creates a message or presents personal details.
Changes require a new static record
When a phone number or email changes, the old contact code still contains the old information. Reprinting is necessary unless the original code linked to a stable page that can be updated. Plan for that difference before ordering long-lived material.
Save the approved payload and artwork together. If the card is reprinted later, compare the contact information with the current record before using the old file. Visual consistency does not establish that the information remains current.
The best contact-code workflow combines format correctness, field review and device testing. Each step catches a different class of problem, and none should be replaced by a claim that a scanner opening an import dialog proves the entire card is ready.
Check duplicate-contact behavior
A receiving contacts app may offer to create a new record or merge with an existing one. That behavior belongs to the app and its current contact data. A QR generator cannot promise that scanning a replacement card updates an old record automatically.
During testing, inspect the proposed fields before saving. If a record is merged, confirm that an old phone number or organization has not remained alongside the new one in a confusing way. A clean test contact can help separate payload behavior from existing address-book state.
For a shared business role, consider whether a role-based contact page is more durable than one person's details. Staff changes can make a printed personal record stale even when the organization remains the same. Choose the content ownership model before the card is distributed.
Frequently asked questions
Can a static vCard update saved contacts automatically?
No. The image contains a fixed record. Existing saved contacts and printed images do not change when you edit a new copy.
Which format should I use?
Start with the format that imports correctly on your intended devices. Test vCard and MeCard when support is uncertain, or use a stable profile-page URL.
Should I print contact details beside the code?
Yes, include the essential readable route. It supports people who cannot or prefer not to scan.
Sources
Last checked: . Examples are illustrative inputs, not measured results.
- RFC 6350: vCard Format Specification, RFC Editor. Checked 2026-10-29.
- Barcode Contents, ZXing project. Checked 2026-10-29.
- Scan a QR code with your iPhone or iPad, Apple. Checked 2026-10-29.
- Scan QR codes with your Pixel phone, Google. Checked 2026-10-29.
- Implementation specifications, checked against source code, Tidy QR. Checked 2026-10-29.