What we send to HMRC — and why
This page shows the data our software must send HMRC alongside your tax filings — all of it, in plain words.
The short version
- When software like ours talks to HMRC, UK law makes it send facts about your browser and device — 16 of them for the way we connect.
- This page lists all 16 — most software never mentions them.
- Two of them we honestly can't collect, so we leave them out. We never invent a value.
- At the bottom, you can see live what your own browser would send.
Why we have to send these at all
The law itself: “The software supplier must ensure that the program operates so that it (a) collects, and (b) delivers to the Commissioners, the relevant ancillary metadata.” That's us — any software that files Making Tax Digital VAT or Income Tax returns must send this data with every call. It is not optional and it is not our choice.
Getting it wrong carries a real penalty: up to £3,000 per program, at most once every 12 months, with the same appeal rights as any other HMRC penalty. The exact list of 16 headers below has the force of law under the Commissioners' Directions, which “have effect from 16 October 2023”.
The 16 headers, one by one
For each header, “what it contains” is HMRC's own specification — select the small source marker after it to see the source. “Why HMRC wants it” is our plain-words reading; HMRC doesn't publish per-header reasons, so that part isn't cited.
Headers tagged cannot collect yet are explained fully in the section right after this list.
Gov-Client-Connection-Method
What it contains
Always the fixed value WEB_APP_VIA_SERVER — it says your request travelled from your browser through our servers, not straight from your device.
Why HMRC wants it
Tells HMRC which connection pattern to expect, since different patterns imply different header sets and different fraud checks.
Gov-Client-Browser-JS-User-Agent
What it contains
Your browser's own user-agent string, read straight from navigator.userAgent — the same string most websites can already see.
Why HMRC wants it
Cross-checked against the connection method and other signals, to catch requests that claim to be a browser but aren't.
Gov-Client-Device-ID
What it contains
A random ID with no name attached, held in a cookie our server manages. It persists across your visits so the same device can be recognised again.
Why HMRC wants it
Lets HMRC's fraud systems link activity back to a consistent device over time, without needing to know who you are.
Gov-Client-Multi-Factor
What it contains
One entry per authentication factor you cleared when signing in — its type, the time you passed it, and a hashed reference to the factor, never the raw code, secret or phone number.
Sent when you signed in with a passkey this session: the time you last passed the passkey prompt and a hashed reference to which passkey — never the key itself. Omitted for anonymous use — we don't invent it.
Why HMRC wants it
Signals how strongly your sign-in to our software was verified.
Gov-Client-Public-IP
What it contains
The public internet address your device is browsing from, right now.
Why HMRC wants it
A core fraud signal — flags patterns like one account filing from wildly different places within minutes.
Gov-Client-Public-IP-Timestamp
What it contains
The exact moment, to the millisecond, that we captured your public IP address.
Why HMRC wants it
IP addresses change; pinning the exact capture time lets HMRC line it up against everything else about that same instant.
Gov-Client-Public-Portcannot collect yet
What it contains
The specific network port your own browser used to send this request — never a server port such as 443.
Why HMRC wants it
Another device-fingerprinting signal, used the same way as Public-IP.
Gov-Client-Screens
What it contains
Your screen's width, height, scaling factor and colour depth.
Why HMRC wants it
A device fingerprint — genuine devices report consistent, plausible screen data; automated or spoofed requests often don't.
Gov-Client-Timezone
What it contains
Your device's timezone offset from UTC, formatted as UTC±hh:mm.
Why HMRC wants it
Cross-checked against where your IP address appears to be, for consistency.
Gov-Client-User-IDs
What it contains
The identifier you're signed in with inside our software — your account's ID once you're signed in, otherwise the anonymous session ID. Never your real name or your HMRC login.
Why HMRC wants it
Links this request to one account inside our software, so HMRC can build a picture across every API call from the same user.
Gov-Client-Window-Size
What it contains
The pixel width and height of your actual browser window — not your whole screen.
Why HMRC wants it
Another fingerprint signal, cross-checked against Screens.
Gov-Vendor-Forwarded
What it contains
The chain of servers, by IP address, that carried your request from us onward to HMRC.
Why HMRC wants it
Lets HMRC check that the IP addresses named in every other header line up honestly with each other.
Gov-Vendor-License-IDscannot collect yet
What it contains
Hashed licence keys for any licensed software installed on your device.
Why HMRC wants it
Flags fraud patterns HMRC has seen tied to licensed software elsewhere.
Gov-Vendor-Product-Name
What it contains
Our product's own name — always TaxSorted.
Why HMRC wants it
Identifies which piece of software actually sent the request.
Gov-Vendor-Public-IP
What it contains
Our own server's public IP address.
Why HMRC wants it
Identifies us as the vendor, and is cross-checked against Vendor-Forwarded.
Gov-Vendor-Version
What it contains
Version numbers for both our frontend and our server.
Why HMRC wants it
Lets HMRC correlate a fraud pattern with a specific software release, in case an issue turns out to be version-specific.
Two headers we honestly can't send yet
HMRC's own rules allow this: “If you are unable to submit a header, you must contact us to explain why … After discussing a missing header with us, you can omit the header or submit it with an empty value. You must not include a placeholder value, for example null or undefined.”
We follow that route for two headers today. Each will be raised with HMRC's [email protected] before we apply for production access (the drafts are written, not yet sent). Neither is ever guessed at or filled in with a fake number.
- Gov-Client-Public-Port — We run behind Fly.io's proxy, which exposes the server port your browser connected to, never the ephemeral source port your own browser used. That source port is genuinely unobtainable from where our server sits.
- Gov-Vendor-License-IDs — TaxSorted is free, open-source software. There is no licensed component on your device to hash a licence key for.
What HMRC does with this data
HMRC's own public Data Protection Impact Assessment for this system (“Transaction Monitoring”, TxM) says it “records customer activity across HMRC customer facing services … to detect suspicious behaviours which might indicate fraud or crime”; alerts are reviewed by a human, never a fully automated decision.
HMRC relies on its own public task, not your consent: “TxM are not required to seek consent from customers.” HMRC's lawful basis is “Article 6(1)(e) of the GDPR” — public task — because “the collection and supply of this data is mandated by Statutory Instrument.”
It is kept for “6 years + current year” — HMRC says this follows its own records management and retention and disposal policy — and “may share TxM data with other government departments, the Police and the National Cyber Security Centre for the purposes of prevention and detection of crime.”
What we do not do: nothing beyond passing this data on to HMRC as the law requires. We don't keep our own separate copy of your fingerprint data beyond what transporting the request itself requires.
Our own legal basis for collecting it
Our collection and onward transmission of this data fits UK GDPR (the UK's data-protection law), Article 6(1)(c) — legal obligation: “processing is necessary for compliance with a legal obligation to which the controller is subject.” The obligation we point to is SI 2019/360 and the Commissioners' Directions above.
One consequence is worth saying plainly: under this basis, “the individual has no right to erasure, right to data portability, or right to object” for this specific processing. That's the law's own trade-off, not ours — we're telling you rather than burying it.
You can block this — here's what that means
The law itself carves this out: “The program is not required to collect or deliver relevant ancillary metadata to the extent that the person using it … has blocked the collection of, or manipulated, such metadata.” If your browser settings block something we'd normally collect — a script, cookies, a fingerprinting API — that doesn't put us in breach of our legal duty.
The honest caveat: these headers exist to help HMRC's fraud systems recognise genuine activity. Block collection, and those systems have less to go on — so they may look at your account more closely, not less. That isn't a threat from us; it's the logical shape of a system built to flag missing or unusual data.
This is what your browser would contribute right now
Built from the exact same code that runs on every real request — not a mock, not a re-typed example. Nothing here is sent anywhere by loading this page; it's a preview, computed locally, of the same four values your browser would hand over the next time we actually call HMRC.
| Header | Your value, right now |
|---|---|
| Gov-Client-Timezone | Reading your browser… |
| Gov-Client-Screens | Reading your browser… |
| Gov-Client-Window-Size | Reading your browser… |
| Gov-Client-Browser-JS-User-Agent | Reading your browser… |
These four are the only ones your own browser computes — reading straight from window.screen, window.innerWidth/innerHeight, navigator.userAgentand your device's clock, the same values any website could already read. Nine of the other twelve headers are added by our server when it actually calls HMRC — a device/session cookie, your IP address as our server sees it, and our own vendor details — and the remaining three are the ones we honestly can't collect (see the section above). None of the server side is something this page, running in your browser, can see or verify. We show you what we can genuinely show you, and describe the rest rather than guess at it.
Sources
Every official page this guide relies on. Links open in a new tab.
- SI 2019/360 — the ancillary metadata regulations (opens in a new tab)
- Commissioners' Directions — the exact header list (opens in a new tab)
- HMRC header specification for web apps via server (opens in a new tab)
- HMRC fraud-prevention guidance: getting it right (opens in a new tab)
- HMRC Transaction Monitoring — Data Protection Impact Assessment (PDF) (opens in a new tab)
- ICO guide to the legal-obligation lawful basis (opens in a new tab)