Privacy and Cookie Policy

Last updated: 11 October 2026

Track QR is a free, privately operated, non-profit service for creating QR tags and exchanging information about tagged items. This policy explains how personal data is used when you visit t-qr.com, create an account, scan a tag or submit information.

1. Who is responsible and how to contact us

Show data controller's name

The data controller is the person responsible for deciding how Track QR processes personal data. For privacy questions or requests about your data, use the email address available below. You can also use the contact page.

Show contact email address

2. Information we process and why

Abuse reports: we store the reported tag/event identifiers, your selected reason and description, optional contact email, signed-in account identifier, timestamps and review status. A keyed hash of your connection’s IP address is used to limit repeated reports; the reporting system does not store the raw IP address. Reports are available to administrators. Closed reports are removed from active storage after 90 days when the reporting system is next used. Encrypted content, tag passwords and full tag links are not automatically attached. Include only information needed to explain the issue.

For encrypted tags, the content fields described in section 3 are received and stored in encrypted form. The account, metadata and technical records listed below remain separate from that content encryption.

• Accounts and tags: your email address, password hash or Google sign-in information, account settings, tag identifiers, categories, tag text and uploaded tag images. These are used to provide the service you request. Our legal basis is performance of our agreement with you (GDPR Article 6(1)(b)). We do not receive your Google password.
• Image review: the data controller and authorised administrators may manually review uploaded images to determine whether they violate our Terms and Conditions. No automated image review is used. Where images contain personal data, we rely on our legitimate interest in preventing misuse and enforcing the service's terms (GDPR Article 6(1)(f)).
• Optional contact details: name, address and phone number can help prefill tags and supply the owner information selected in category settings. Providing these details is optional; leave unnecessary fields blank and check what each tag displays or prints. We use the details you choose to provide to deliver those requested features under our agreement with you.
• Posts and optional position: event type, text, any email address you provide, submission time and optional coordinates. We use these to show your post according to the tag's settings and notify its owner. We rely on the consent requested when you submit. You may post without an email address. Position is optional: select Provide position to request it and Clear position to remove it before submitting. Filling in the post form does not automatically request your position.
• Scan and visit events: the tag, time, event type and, if you are signed in, the account associated with the action. Depending on tag settings, these events help owners follow activity on their tags. We rely on our legitimate interest in providing the tag activity function (Article 6(1)(f)).
• Technical and security records: visit information and login/security activity, including IP addresses or derived IP values and timestamps. These support troubleshooting, abuse prevention and protection of accounts. We rely on our legitimate interest in running a secure, reliable service.
• Support: information you send through the contact form or by email, used to respond to you. The legal basis is our legitimate interest in handling enquiries, or performance of our agreement when the enquiry concerns your account.
• Optional browser notifications: a push subscription address, delivery keys and delivery records allow notifications to reach your browser and help avoid repeated messages. We use this optional channel with your consent. You can stop notifications in your browser's site settings.

IP addresses are not stored with new tag events or included in event notification emails. Separate visit, login and server security logs may contain IP information.

Do not put unnecessary personal information, sensitive information or information you are not entitled to share into tag text, images or posts. A post without an email address can still identify someone through its text or position.

3. Who can see tag information and posts

Tag owner controls

Tag owners choose category settings that control visibility, posting permissions and moderation. Depending on those settings, people with the tag link may see its text, owner details, posts and shared coordinates. Treat a publicly accessible tag link as shareable. Printed information can be read by anyone who sees the label.

For unencrypted posts, the full address in the email field is available to the tag owner and through authorised post-management access. Other viewers permitted by the tag settings may see a masked version. If you write an email address or other contact details in the comment itself, they follow the comment's visibility settings.

Unencrypted posts may be sent to the tag owner by email. For encrypted posts, notifications do not contain the encrypted text, email address or coordinates. Notifications for encrypted tags identify the tag by number rather than its encrypted name. They can still show unencrypted information such as the event type, including on a device's lock screen. We cannot remove printed labels, screenshots or copies already delivered to another person's mailbox.

Encrypted tags and shared passwords

Each new encrypted tag receives its own automatically generated password, including when several tags are created together. Existing tags retain their original passwords. The password is shared with anyone given the full tag link or QR code; it is separate from the account sign-in password.

For encrypted tags, tag names, tag details (custom information, contact details, notes, selected owner information and coordinates) and a post's text, email address and coordinates are encrypted in the browser before being sent to Track QR. They are decrypted in the viewer's browser. The normal posting and reading flow does not send the tag password to the server; we store the encrypted content and cannot recover a lost tag password.

The tag owner controls how the full tag link, QR code and password are initially shared, as well as the tag's visibility, posting, moderation and retention settings within the service's limits. Anyone who obtains the full link or password and can access the encrypted content can read it, including email addresses inside encrypted posts. This is not restricted to the owner. A QR code containing the full link also gives its holder the password. Recipients can copy or share the link, password or decrypted information; changing access settings or deleting the tag cannot recall those copies.

Not everything is encrypted: tag identifiers, account associations, category and access settings, event types and timestamps remain available to the service. Separate technical and security records are also outside the tag's content encryption. Images on encrypted tags follow the separate processing and review procedure below. Contact details stored in your server account remain separate from tag encryption. You can instead choose local storage as described below.

Tag owners are responsible for how they collect, use and share information for their own purposes. Where an owner determines the purposes and means of processing personal data, they may have their own data-controller obligations. Track QR remains responsible for the processing it determines, including account administration and service security. Encryption and possession of a password do not by themselves settle the legal roles or remove data-protection obligations.

Changing a tag’s encryption or identifier

The tag owner can convert an existing tag between encrypted and unencrypted when all events outside the trash belong to that owner. Accounts restricted to encrypted tags cannot convert tags to unencrypted. Existing unencrypted tags on those accounts remain usable and editable. Conversion includes the saved tag content, remaining events and existing image. Removing encryption makes the protected content readable by the server and by viewers allowed under the category settings. Owner information then follows the current account and category settings instead of the encrypted owner-information copy. Encrypting previously unencrypted content does not erase copies already shared, downloaded or retained in older backups. An already approved image keeps its review status.

Changing a tag’s identifier breaks its old links and QR codes but does not recall information already copied by others. Changing the identifier or converting the tag permanently deletes its trashed events from active storage. Backup copies remain subject to the retention period in section 5.

Optional local contact details and encrypted vault

In Account, you can choose to store your personal contact details only locally. When you save this choice, the browser first saves an encrypted copy and the service clears the name, address, postal code, city, state, country and phone fields from your active server account. Your sign-in email remains on the server. Existing copies in tags, printed labels and backups are not removed by this choice. For accounts restricted to encrypted tags, local contact storage is required when saving account details. Enabling this restriction does not immediately remove existing server contact details: they remain until you save an encrypted local copy through Account. For unrestricted accounts, turning the option off and saving stores the displayed details in your server account again.

This option is suitable only if you use encrypted tags: unencrypted tags cannot use the local profile. Your browser can use it to fill encrypted tag owner information and printed contact information, respecting category settings. Updating your profile does not automatically replace information already encrypted inside tags; you can review or sync owner information after unlocking the tags.

You can optionally sync saved tag passwords and local contact details through an encrypted vault stored on the server and associated with your account. The browser encrypts the vault contents using a separate vault password; the normal sync flow does not send that password or the recovery key to the server. We process this encrypted copy and its account association to provide the sync feature you request under our agreement with you. Local storage encryption uses a different, server-held account key, as explained in section 8.

Keep the vault recovery key outside the browser. It lets you set a new vault password if you forget the old one. Resetting your account sign-in password does not unlock the vault. If you lose both the vault password and recovery key, reset cannot recover the encrypted contents; you need any remaining local copies or exported backups.

Images on encrypted tags

Only the signed-in tag owner can upload or replace a tag image. The image is sent over HTTPS in a form the server can read. The server checks, resizes and re-encodes it, then encrypts it using a public key supplied by the browser. The browser creates a separate key pair for each upload; the private key is stored only in encrypted form, protected by the tag password. The viewer's browser decrypts the image after the tag is unlocked. Unlike the protected text fields, image uploads are not end-to-end encrypted.

We keep encrypted image data in access-protected files on the server. Encryption metadata and a separate unencrypted review copy are stored in the database. Access to the review copy through the service is restricted to authorised administrators; it has no public image address. The encrypted image is available to viewers who can unlock it while review is pending. Images are normally reviewed within 24 hours, but this is a usual processing time, not a guaranteed maximum retention period.

Approval deletes the unencrypted review copy from active storage and retains the encrypted image. Rejection deletes both copies. Replacing an image removes the previous stored versions and starts a new review. Deleting the image, its tag or the owning account removes both stored copies from the live service. Backup copies are subject to sections 5 and 6.

Optional email recovery for encrypted posts

If you select Allow me to delete this post later by verifying my email when saving a post, your browser sends a fingerprint of the email address separately from the encrypted content. The server protects that fingerprint with a secret key and stores it with the post. This lets us match an email address you later provide, verify access to that mailbox and give you post-management access. It also allows posts using the same recovery address to be linked. The fingerprint is not anonymous data, and the recovery address is processed in readable form when you request an email link.

This option is off by default and used with your consent. It does not give us the tag password or decrypt the post. A verified recovery link lets you delete a linked post without unlocking the tag; reading or changing its encrypted content still requires the password. You can disable recovery by editing and saving the post with the option unchecked, or delete the post. The deletion and backup periods below still apply.

4. Google sign-in and other external services

Google sign-in is optional. Existing accounts must enable Sign in with Google under Account settings. Accounts created using Google have it enabled when they are created. We receive a Google account identifier, email address and available profile information such as your name to verify sign-in and identify your Track QR account. Two-step verification still applies unless you have chosen to trust that browser.

Opening the Google sign-in option loads Google's sign-in service. Google receives technical connection information and processes the sign-in under its own privacy policy. Disabling Google sign-in in Track QR prevents future use of that sign-in method; it does not delete your Google account or Google's records.

Selecting a map link opens Google Maps and sends the selected coordinates to Google. The optional map picker loads Google Maps when you select Open Google Maps. Google receives technical connection information and map requests and may use cookies or browser storage. You can instead use browser location or enter coordinates manually. A position selected on the map is saved when you submit your post or create your tag. Optional push notifications use your browser's push provider, which may be operated by Google, Apple, Mozilla or another provider. Push payloads are encrypted for delivery, but the provider processes the connection and delivery information needed to operate its service.

Hosting and email infrastructure also process data needed to run the site and deliver messages. Recipient categories therefore include our infrastructure providers, the external services you choose to use, and the tag owners and viewers described above. Personal data may also be disclosed where a legal obligation requires it. Track QR does not use your posts or account details for advertising.

Embedded instructional YouTube players load automatically when you open a page containing a video. Playback starts when you press Play. This connects your browser to YouTube/Google using the youtube-nocookie.com embed domain. YouTube may process connection and playback data and use browser storage under Google’s privacy policy. The connection to YouTube/Google is made even if you do not start playback.

5. Storage location and backups

The service's server is in Germany. Encrypted local backups are kept on the operator's own laptop, currently in Sweden. We do not use cloud backups outside the EU. Each backup is retained for a maximum of three months after creation and is then deleted. Backups are used only for recovery. Images awaiting approval are excluded from backups. For encrypted tags, this includes both the encrypted image and its unencrypted review copy while approval is pending. After approval, the retained encrypted image may be included in backups; the unencrypted review copy has been deleted.

Google and browser push providers may process information outside the EU/EEA. Their privacy information describes their locations and safeguards; see Google's privacy policy and the privacy information for your browser's push service. Contact us for information about the recipients and safeguards relevant to your use of Track QR.

We will review the protection of personal data and update this policy before changing the operator's location or backup arrangements. Agreeing to this policy does not authorise unrestricted transfers to any country.

6. How long information is kept

Unless stated otherwise, the same retention and backup periods apply to encrypted and unencrypted records. Images awaiting approval are excluded from backups as described in section 5. Recovery fingerprints are stored with their posts and are removed when recovery is disabled through editing or the post is permanently erased. Hiding a post does not immediately erase its encrypted content or fingerprint.

• Account details, tags and tag images: while the account and tags are in use, until you remove them or request deletion. The shorter retention rules for unencrypted review copies below apply separately.
• Encrypted vault and local data: the server vault remains until reset or account deletion. Reset removes its current encrypted contents from active storage but keeps a revision record; existing backups follow the backup retention period. Local browser copies remain until removed or site storage is cleared. Synced changes and removals reach other devices when they next sync; downloaded exports are not updated or deleted remotely.
• Unencrypted review copies for encrypted tag images: kept pending review, normally completed within 24 hours, and deleted from active storage when the image is approved or rejected. They are also removed if the image is replaced or deleted, or its tag or owning account is deleted. There is currently no automatic maximum retention period for images still awaiting review.
• Tag events and posts: the tag category sets an expiry period, up to seven years, and the posting form shows a date. Expired records are permanently removed when cleanup runs as tag or event pages are accessed; the displayed date does not guarantee physical erasure on that exact day. Display limits and moderation may hide posts earlier. Visit and scan events on tags follow these settings separately from the 30-day technical visit log.
• Deleted tags and posts: ordinary deletion can first hide a post and leave a record awaiting permanent cleanup. Account deletion permanently removes the account's own tags and their events as described below. Contact us if you need help with permanent erasure of an individual post.
• Abuse reports: new reports and reports under review remain until handled; no automatic maximum retention period is currently set for open reports. Closed reports are deleted from active storage once their last update is more than 90 days old, when a report is submitted or the administrator opens the report queue. Closing a report does not delete the reported tag or event. Backup copies follow section 5.
• Application visit and login/security logs: the retention limit is 30 days. Entries older than this are removed when the cleanup job runs.
• Sessions and login tokens: session access ends when the session expires or you sign out. Optional saved-login authorisation lasts up to 30 days; trusted-browser authorisation lasts up to 90 days without automatic extension when used. Expired tokens no longer grant access, but their stored records may remain until revoked or the account is deleted. Account deletion also removes used verification-code records.
• Push records: disabling notifications stops sending; revoking browser permission stops notifications in that browser. These actions may leave subscription or delivery records on the server. Subscriptions reported as expired during delivery are removed. Account deletion removes remaining subscriptions and delivery records.
• Apache web server logs: access and error logs are retained for 14 days, then deleted.
• Other routine troubleshooting logs: retained only as needed to diagnose and resolve technical problems, for a maximum of 90 days. The separate limits of 14 days for Apache logs and 30 days for application visit and login/security logs apply to those records.
• Other server-level security logs: logs needed to detect and investigate unauthorised access or other security incidents are retained for a maximum of six months, then deleted. This period does not extend the shorter limits for Apache or application logs.
• Incident-related log extracts: relevant extracts from logs relating to a specific incident may be retained beyond their normal retention period where necessary to investigate that incident or establish, exercise or defend legal claims. The continued need for these extracts is reviewed regularly, and they are deleted when no longer needed. This exception does not extend retention of unrelated logs.
• Support correspondence: kept as needed to answer the enquiry or resolve the related issue. No fixed maximum period has been established for this correspondence. The log retention limits above do not apply to support mailboxes.
• Backups: retained for a maximum of three months after creation, as described in section 5. Images awaiting approval are not included in new backups. Deleting live data does not immediately erase existing backup copies; remaining copies are deleted within that retention period. If an older copy is restored, we will reapply deletion requests before returning the restored data to use.

7. Deleting an account or managing posts

Delete account permanently removes the account and its own tags, tag events, uploaded tag images, saved logins and push records from the live service without a one-month waiting period.

Account deletion removes the encrypted vault and the server-held local encryption key from active server storage. It does not erase browser storage on other devices or downloaded exports; remove these copies yourself. Server backups follow the retention period in section 5.

Deleting an account, tag or event does not automatically delete related abuse reports. Their descriptions, optional contact email, stored account and content identifiers, keyed IP hash and review records remain subject to the report retention rules in section 6. Contact us if you need help with personal information in a report.

During deletion you choose whether posts you made on other owners' tags should also be deleted or retained. For retained posts, the account association and the separate unencrypted email, IP address and coordinate fields are cleared. Text, event type and timestamp remain subject to the tag's retention settings. Encrypted content is retained unchanged: we cannot selectively remove an email address, position or other personal information from inside it. An existing recovery fingerprint may also remain, but no longer grants access to these detached posts. Retained posts are therefore not necessarily anonymous. Choose deletion if you do not want their content retained. You lose account-based access to manage retained posts; contact us if you need help exercising your rights.

Guests can manage new posts through the session in which they were created. The server remembers the relevant post identifiers in the existing session. After that session ends, unencrypted posts may be accessed through an account or verification of the email used for the post. Encrypted guest posts require email recovery to have been enabled before that access was lost. Posts made while signed in can be managed through the posting account.

Older encrypted posts without a recovery fingerprint cannot be found by their encrypted email address. If you still have author access, you can unlock and edit the post to enable recovery. Knowing a tag password alone does not prove that you wrote a particular post or grant permission to delete it. Without author access or a recovery link, we may be unable to verify who submitted an older post.

8. Cookies and browser storage

We use session and security cookies to operate requested features, prevent forged submissions and maintain authenticated access. Optional persistent login features are used when you select them.

• Session cookies, including sessionid: maintain login, security checks, forms and guest post-management access; session lifetime.
• timeoffset: remembers the time-zone offset used to display dates; session lifetime.
• keepme: optional “Keep me signed in” token; up to 30 days.
• Trusted-[account number]: optional trusted-browser token that skips the local security code after primary sign-in; up to 90 days. Remove trusted browsers in two-step-verification settings to revoke it.
• gotit: remembers dismissal of the cookie information notice; up to one year.
• email: may maintain access after you follow an email-notification management link; session lifetime.
• Browser preferences and push storage: a sound preference may be stored locally until cleared. Browser-managed service-worker and push data support notifications you enable.
• Automatic saving of new tag passwords: the optional choice is remembered per account in this browser until changed or site storage is cleared. When enabled, passwords for newly created encrypted tags are saved in encrypted browser storage. Converting an existing tag to encrypted always saves its new password there before conversion, regardless of this creation preference; conversion stops if the password cannot be saved. Saved passwords can subsequently be included in vault sync when you use that feature.
• Tag passwords in session storage: unlocking a tag keeps its password in memory and, for signed-in accounts when available, encrypted in this tab's session storage. Temporary copies are bound to the account and login session. Selecting Lock again clears the tab's remembered password and locks the displayed content; it does not delete an explicitly saved password.
• Saved passwords and local contact details: these browser copies, including local vault sync history, are encrypted using an account-specific key held on the server and loaded into memory after an authenticated check. They are separated by account. Existing readable saved entries are encrypted when loaded. Signing out clears temporary access but does not delete persistent encrypted copies. This protects stored browser copies; it does not protect against scripts running in an authenticated page, a compromised server or someone using an already unlocked page.
• Changing the local encryption key: re-encrypts the current browser's saved data. Other devices must restore their saved data from an exported backup or unlock and sync the vault. This does not change the vault password or tag passwords.
• Automatic vault sync: the optional preference is stored per account. While unlocked, the browser can sync saved changes and removals, including removal of saved tag passwords. Manual sync does not retain vault unlock across reloads. Choosing Automatic sync — 8 hours stores the vault key, login binding and expiry in session storage for up to eight hours, allowing sync after reload; it does not store the vault password. Explicitly locking sync clears this remembered key. Browser session restoration may preserve tab storage, so use the lock control on shared devices.
• Remembered vault unlock on a private device: when Automatic sync — 30 days is explicitly selected, the vault key, login binding and expiry are stored in persistent browser storage, encrypted using the server-held account key, for up to 30 days. This also enables automatic sync. The vault password is not saved. Enable Keep me signed in when signing in to retain remembered vault access after closing the browser. The saved login must remain valid; a new browser session alone does not clear it. Remembered access requires the same valid login and is cleared on sign-out, login changes or explicit vault locking. This reduces the protection provided by a separate vault password: anyone using your signed-in browser, scripts running in an authenticated page or a compromised server may access the vault key. Use this option only on a private device that nobody else can access.
• Exports and shared links: exported backups contain readable tag passwords and may include local contact details. Full tag links and QR codes can also contain tag passwords. Keep them private and delete unwanted copies yourself; clearing site storage, resetting the vault or deleting an account does not recall them.

You can delete or block cookies and clear site storage in your browser. This may sign you out and remove your guest session's ability to manage posts. Browser settings can also revoke location and notification permissions. Google's optional sign-in flow may use Google's own cookies or storage; see its privacy information. A cookie's stated lifetime is a maximum for that issuance, and your browser may remove it sooner.

9. Your rights

These rights also apply where relevant to encrypted personal data. We can help with stored records and deletion after appropriate verification, but cannot read, search within or selectively correct encrypted content without its password. Do not send us a tag password; use the browser controls where possible, or contact us with the tag or post identifier. A tag owner may also need to handle requests concerning their own use of the information.

Depending on the circumstances, you may request access to your personal data, correction, deletion, restriction or data portability. You may object to processing based on legitimate interests. Where processing relies on consent, you may withdraw it without affecting the lawfulness of earlier processing.

Use the account and post controls where available, or contact us using section 1. Clearing position before submitting prevents its inclusion; to withdraw consent for a position already posted, edit or delete that post, or contact us. We may need proportionate information to verify your identity. We normally respond within one month; if a permitted extension is needed, we will explain why within that first month.

You may complain to the Swedish Authority for Privacy Protection (IMY) or another competent EU/EEA supervisory authority. We do not use solely automated decisions or profiling that produce legal or similarly significant effects on you.

10. Security and changes

We use HTTPS, access controls, password hashing, authentication-token protection and optional two-step verification to protect the service. Please use a strong password, keep access to your email secure and trust only browsers you control. No service can guarantee absolute security.

The service is intended for adults aged 18 or over. Contact us if you believe a child has provided personal data that should be removed.

We will update this policy when processing changes. Material changes will be highlighted on the site or communicated through an appropriate channel. The date above identifies this version; reading or using the site is not blanket consent to every kind of processing.