html2wp / Data
What html2wp does with your data
A plain description of what leaves your machine, why, and how long it is kept. The README says the same things in passing; this is the version you can point a client at.
The conversion itself
To convert a site, the service has to receive it. When you run stage 3, the skill uploads one archive to api.html2wp.dev:
conversion-manifest.json, the decisions you made about the siteastro-report.json, the chrome inventory from stage 1astro-project/, includingdist/, which is the built sitechrome-at-rest/,chrome-groups.jsonandstyle-specimens/when they exist
That is your client's website: its markup, styles, scripts and images. There is no way to convert a site without sending it, and any wording suggesting otherwise would be false. SKILL.md lists the exact members under What goes up, and convert-remote.sh is a readable shell script if you would rather check than take our word for it.
What is not in that archive
Your input directory, since only the built output travels. node_modules. And anything shaped like a credential: .env and .env.*, *.pem, *.key, id_rsa, credentials.json, .npmrc, .netrc, .ssh/, .aws/, plus any file whose contents contain a private key block or an obvious secret assignment. Everything the filter drops is listed by name in astro-report.json, so you can see what did not travel.
How long it is kept: the workspace is deleted 7 days after it stops changing. What survives is a digest, a hash, which is what lets a re-run of the same site count as a re-run rather than a second conversion.
The gate results
After you verify a conversion locally, the skill reports the outcome. This is required: the next conversion is refused until the previous one has reported. It is also small, and it is a whitelist rather than a filter.
- Sent: gate names, pass, fail or not-run, page counts, the worst fidelity percentage, and the page keys that failed, which are the short names you chose, like
aboutorpricing. - Not sent: no URL, no domain, no markup, no copy, no screenshots, no file paths, no licence key, no site name.
send-verdicts.sh <workspace> --dry-run prints the exact payload and sends nothing.
Why it is required: the gates run on your machine, against a WordPress the service never sees. Without them the service can tell that a conversion did not crash and nothing whatsoever about whether it was correct. Kept 365 days.
The conversion record
One row per conversion: how many pages, how many chrome variants, whether it had a blog or a shop, whether it was a re-run, which stage refused if one did, and the generator's own warnings about itself. The warnings are redacted, with page filenames and URLs replaced before the row is written. Kept 365 days. No content, no addresses, no identifiers for the site.
Defect reports
If you send one with POST /v1/report, the body is stored as you wrote it and read by a person. Kept 90 days. Do not paste anything into it that you would not want kept for that long.
Identifying you
- Without a key: counted per IP address, as seen by Cloudflare. Stored as a truncated hash, never as an address.
- Licensed: by the licence key, also stored as a hash. Validated against UpdatePulse (
updates.designready.studio), which sees the key.
Who else is involved
- Cloudflare, which sits in front of the API. It terminates TLS, so it sees the request and the address it came from.
- UpdatePulse on our own server, for licence validation.
- Coolify on our own server, for hosting.
- Plausible Analytics, on this website only. It counts page views and a handful of clicks — which button was pressed, not who pressed it. No cookies, no cross-site identifier, nothing stored on your device, which is why this site has no cookie banner to click through. It is hosted in the EU.
No advertising, no cross-site tracking, no data sold
The one analytics tool is the cookieless one named above, and it runs on this website. The theme you receive contacts no server of ours at runtime, ever — that claim is about the delivered site, and it is exact. Nothing is sold, and nothing is shared with an advertiser.
Leaving the EU
Our servers and Plausible are in the EU. Cloudflare is a US company, so traffic to the API passes through infrastructure that can involve a transfer outside it; that transfer runs on the European Commission's Standard Contractual Clauses. Nothing else in this list leaves the EU.
Why we are allowed to
Under the GDPR every one of these needs a lawful basis, so here is which one, for each:
- Receiving and converting your site — performance of a contract (Art. 6(1)(b)). You asked for a conversion; it cannot happen without the upload.
- Counting conversions against an IP address — legitimate interests (Art. 6(1)(f)). A free tier that cannot be counted is a free tier that gets drained, and a truncated hash is the least we could identify it with.
- Validating a licence key — performance of a contract (Art. 6(1)(b)).
- Gate verdicts and the conversion record — legitimate interests (Art. 6(1)(f)): knowing which stage fails on which shape of site is the only way the converter improves. They are stripped of the site's identity before they are written.
- A defect report you send — legitimate interests (Art. 6(1)(f)), and you decide whether to send one at all.
- The request form — steps taken at your request before a contract (Art. 6(1)(b)).
- Counting page views on this website — legitimate interests (Art. 6(1)(f)), which is defensible precisely because the tool stores nothing on your device and cannot follow you off this site.
Automated decisions: the service refuses a conversion automatically when an allowance is spent or a site is too large. That is arithmetic on a counter, it produces no legal effect on anyone, and a person answers if you write to us about it. There is no profiling.
The request form
Asking for a licence key is the one place on this site where you type something about yourself. The form takes a first name, an email address, a website or profile and optionally a company. The website is the part that matters to us — it is what we look at to answer.
It goes to a person by email, not into a CRM and not onto a mailing list. We keep it while the request is open and for 24 months after, so that a key issued in beta can be traced to the person it was issued to. Ask sooner and it goes.
Your rights
Under the GDPR you can ask us for any of the following, and one email is enough: hello@html2wp.dev.
- Access — a copy of what we hold about you (Art. 15).
- Rectification — correct it if it is wrong (Art. 16).
- Erasure — delete it (Art. 17).
- Restriction — keep it but stop using it while something is in dispute (Art. 18).
- Portability — receive what you gave us in a machine-readable form (Art. 20).
- Objection — object to anything we do on the basis of legitimate interests, including the analytics (Art. 21). We stop unless we can show grounds that override yours.
We answer within one month. There is no charge, and we do not ask you to prove who you are beyond what it takes to be sure we are not handing your data to somebody else.
One honest limit: most of what the service holds is hashed or aggregated and cannot be traced back to a person even by us, so for those rows there is nothing to hand over, correct or delete. The uploaded site is gone after 7 days by itself.
If we get it wrong
You can complain to the Slovak supervisory authority: Úrad na ochranu osobných údajov Slovenskej republiky, Hraničná 12, 820 07 Bratislava, dataprotection.gov.sk. If you live in another EU country you may go to your own authority instead. Writing to us first is faster, but it is not a condition.
Vulnerability reports go to the address on the security page, not to a public issue.
Who is responsible
The data controller is BELNEM s.r.o., Beckovska 5, Bratislava, Slovakia, IČO 53713486 — hello@html2wp.dev. We are not large enough to be required to appoint a data protection officer and have not appointed one; the address above reaches the people who decide these things.
Giving us data is never a statutory requirement. It is simply that a conversion needs the site, and a licence needs an address to send a key to.