Does Clerk Work in China? Data Residency, PIPL Cross-Border & User Identity Data
Clerk is drop-in authentication, so the real China question isn't whether the login screen loads — it's where the identity data of your China users lives. Clerk's own security page says it offers no regional data residency or region selection: everything is US-hosted (Google Cloud and Cloudflare), so the emails, phone numbers, profiles, authentication factors and sessions it holds for your mainland users rest offshore, making their collection a cross-border transfer of personal information under PIPL. A compliance-first look at the data-residency, consent and ICP questions — and the lawful in-country path.
Does Clerk work in China?
Whether you can run Clerk for a mainland-China audience is first a data-residency and consent question under PIPL, not a speed one. Clerk is drop-in authentication — it holds your users' email addresses, phone numbers, profiles, authentication factors and sessions — and where it keeps that identity data is what China's law responds to.
Clerk's own security page is blunt: it "does not offer regional data residency or region selection," and data is "hosted on US infrastructure (Google Cloud and Cloudflare, with all subprocessors in the USA)." So the identity record of every China user who signs in sits offshore — a cross-border transfer of personal information PIPL governs (notice, a separate consent and one transfer mechanism, Articles 38–40), with an in-country storage duty for a CIIO or large-volume handler (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)). Authentication data can also count as sensitive personal information, carrying a heightened consent duty. The table below is Clerk's own wording and the rule each line triggers.
This is a risk map, not a verdict — what you owe turns on your data volumes, your role as handler and who your users are, and it's worth settling with counsel. Our China team can map your exposure with you →
What Clerk's own documentation says about China
| Fact | Primary source |
|---|---|
| Clerk says plainly it offers no regional data residency. On its own security page, Clerk answers "Does Clerk offer regional data residency?" with: "No. Clerk does not offer regional data residency or region selection. Data is hosted on US infrastructure (Google Cloud and Cloudflare, with all subprocessors in the USA)…" There is no mainland-China region — and no EU region — to keep your China users' identity data in-country, so collecting it into Clerk is a cross-border transfer of personal information under PIPL (notice, a separate consent and a transfer mechanism, Articles 38–40). | Clerk — Security and Compliance at a Glance (FAQ: regional data residency; last reviewed by Clerk 2026-08-17), retrieved 2026-10-09; PIPL Articles 38–40 |
| There is no nearer region to switch to. Clerk's security page states its data is "hosted on US infrastructure (Google Cloud and Cloudflare, with all subprocessors in the USA)," and that "EU, UK, and Swiss personal data is transferred to the US under the Data Privacy Framework" — Clerk's GDPR-compliance mechanism, self-certified effective Feb 22, 2024. So even EU, UK and Swiss data ends up in the US; keeping China identity data in-country is not a setting to flip but a China-resident footing to stand up. | Clerk — Security and Compliance at a Glance (FAQ: regional data residency; DPF self-certification), retrieved 2026-10-09 |
| What Clerk stores is your China users' identity — and some of it may be sensitive. Clerk is drop-in authentication and user management: it holds the email addresses, phone numbers, profile fields, authentication factors and live sessions of everyone who signs in to your app. For users in mainland China that is a continuous record of identifiable people held in a US-hosted service, and some fields — a biometric factor behind a passkey, or data about a minor under 14 — can count as sensitive personal information under PIPL, which adds a heightened, specific consent and a necessity test to the ordinary transfer duty. | Clerk product & security documentation (user, session and authentication data), retrieved 2026-10-09; PIPL Articles 28–29 (sensitive personal information) |
| For some handlers the data must stay in China — and serving the login from inside the mainland triggers an ICP filing. Where the handler is a critical information infrastructure operator or moves personal information at volume, personal information collected in China must be stored in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)) — which a US-hosted Clerk account cannot satisfy. And any public-facing app actually served from inside China must carry an ICP filing (State Council Order No. 292; MIIT Order No. 33), bound to a mainland hosting resource Clerk does not provide. | PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37); State Council Order No. 292; MIIT Order No. 33 |
Sources verified by the 21YunBox compliance team on 2026-10-09.
For an app that signs its users in with Clerk, the first instinct is to ask whether the login screen even loads from inside mainland China. On the wire that is the easy half — and it is not where the China decision is settled. Clerk is drop-in authentication: it holds the identity of everyone who signs in — their email addresses, phone numbers, profile fields, the authentication factors they register and their live sessions. For your users in China, the question that actually decides whether you may run it is where that identity data comes to rest, and whether it had a lawful basis to leave the country in the first place. That is a data-residency and consent question under China’s law, and Clerk answers the first half of it in its own words.
Clerk’s security page is unusually direct about it: it does not offer regional data residency or region selection. Every account — and every identity record in it — is hosted on US infrastructure. So the moment a person in China signs up, the personal information Clerk stores about them sits offshore, and a different body of law decides whether that was allowed.
Clerk in China at a glance
| What decides it | In Clerk's own terms — and China's law |
|---|---|
| What it is | Clerk is a drop-in authentication and user-management service embedded in your web or mobile app. It stores the end-user identity it manages — email addresses, phone numbers, profile data, authentication factors and sessions — so it holds a live record of identifiable people. |
| Is it reachable from the mainland? | Reachability is the operational half, not the decision. Your sign-in and app surface depend on Clerk's Frontend API and client bundle resolving from the mainland, delivered from Clerk's US and global edge; cross-border calls can be inconsistent. That is an operational matter (below), not what decides whether you may use Clerk — and 21YunBox never uses or suggests any way around a network restriction. |
| Where does the identity data sit? | Offshore. By Clerk's own security page it “does not offer regional data residency or region selection,” and data is “hosted on US infrastructure (Google Cloud and Cloudflare, with all subprocessors in the USA).” There is no mainland-China region — and no EU region either. |
| Collecting China identity data into it | The emails, phones, profiles, auth factors and sessions are personal information. Holding them in a US-hosted Clerk is a cross-border transfer (数据出境) under PIPL (Articles 38–40): notice, a separate consent, and one transfer mechanism. Authentication data can include sensitive personal information (a biometric factor behind a passkey, or any data about a minor under 14), carrying a heightened consent and necessity duty. For a critical information infrastructure operator, the Cybersecurity Law's Article 39 (formerly Article 37) sets an in-country storage duty a US region cannot meet. |
| Serving the public | The China-facing login and app surface is itself a public internet service in the mainland, so serving it from inside China turns on an ICP filing bound to a mainland hosting resource — which Clerk's US hosting cannot hold. |
| The lawful path | Put the China users' identity data on a China-resident footing — consented in-country storage, or a China-resident authentication deployment for the China app surface — send offshore only what may lawfully leave, and deliver the China-facing app in-country on ICP-filed infrastructure. 21YunBox maps, localizes and delivers; it never uses or suggests circumvention. |
Availability: reachable or not, the decision is where the identity data lives
Clerk’s China posture is set by where it keeps data, not by a load-time test. Its sign-in widgets, hosted pages and Frontend API are called from the browser or app, and the client bundle and API have to resolve from wherever a user sits — the mainland included. Whether that path is consistent from inside China is a real operational question, and we treat it as one: it is the delivery half, handled further down, not the legal half that decides whether you may use Clerk at all. For that reason this page publishes no first-party China latency or reachability figure for Clerk — speed is not the axis for a decision that turns on residency and consent.
One thing we will say plainly: where cross-border calls are inconsistent, the temptation is to force them through a network workaround. 21YunBox neither uses nor suggests any such circumvention — it is both a compliance risk and beside the point. The productive question is how to keep the China identity data on a lawful footing.
The identity record is personal information — and Clerk keeps it offshore
Here is the gate most teams miss. A Clerk account hosted in the US is, by definition, outside the mainland. The identity records it holds for your users in China — their email addresses, phone numbers, profile fields, the authentication factors they register and the sessions they open — are personal information, and storing them in a US-hosted Clerk is a cross-border transfer of personal information under China’s Personal Information Protection Law. PIPL puts the duty on the handler — you, whose app embeds Clerk, not Clerk the processor: Articles 38–40 require notice, a separate consent distinct from any general agreement to use your app, and one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification.
Authentication data raises the stakes further. Some of what Clerk keeps in order to sign a user in — a biometric factor behind a passkey, or any data belonging to a minor under 14 — can count as sensitive personal information under PIPL, which carries a heightened, specific consent and a necessity test on top of the ordinary transfer duty. Whether any field you collect is sensitive, and what your consent flow must say, is a question to settle with counsel against what you actually enable in Clerk.
No region selection — so no in-country footing, and no ICP
The usual escape hatch is to point the vendor at a nearer region. Clerk closes it in plain terms: it offers no regional data residency or region selection at all — not a mainland-China region, and not an EU one. Its own security page states that data is “hosted on US infrastructure (Google Cloud and Cloudflare, with all subprocessors in the USA),” and that “EU, UK, and Swiss personal data is transferred to the US under the Data Privacy Framework.” So there is no setting to flip that keeps China identity data in-country.
That settles two things before performance ever enters the picture. First, residency: if you are a critical information infrastructure operator or a large-volume handler, personal information collected in China must be stored in the mainland (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37 — the data-localization provision was renumbered by the 2025 amendment that took effect on January 1, 2026, with its substance unchanged)) — a duty a US-hosted account cannot satisfy. Above certain volumes, or where the data counts as “important data,” the transfer may also require China’s data-export security assessment (数据出境安全评估) before anything leaves. Second, licensing: the China-facing app or site that presents the Clerk login is a public internet service in the mainland, so serving it from inside China turns on an ICP filing (备案) bound to a mainland hosting resource — which Clerk’s US infrastructure cannot hold.
None of this is a verdict that Clerk is “blocked” or “illegal.” It is a risk map: which obligations bite turns on your entity, the identity data your app collects, your role as handler under Chinese law, and who your users are — worth settling with counsel before your sign-in flow depends on it.
Why “switch Clerk to another region” isn’t the fix
Because there is no other region to switch to. Clerk does not offer region selection, so there is no US-to-EU toggle to reach for — and even if there were, neither the US nor the EU is in mainland China, so neither would answer a China residency duty. Keeping China-collected identity data in-country means standing up a China-resident footing for it — consented in-country storage and processing, or a China-resident authentication deployment for the China app surface — and sending offshore only what may lawfully leave. That split — what must stay, what may go — is the heart of the work, and it is a legal question before it is a technical one.
The lawful path — map, localize, deliver
There is a compliant way to run authentication for a China-facing app, and it has a shape. First, map: our China team works through your PIPL exposure on both fronts — collecting identifiable users’ data, and transferring it offshore — pinpointing which identity fields gathered in China must stay in the country, what may lawfully leave, where a data-export security assessment or an Article 39 storage duty bites, and what your consent and notice flow has to cover. The legal conclusions are settled with counsel; we build the technical picture that feeds them.
Then localize: we stand up a China-resident footing for the China users’ identity data — consented in-country storage, or a China-resident authentication deployment serving the China app surface — so the sign-in your users depend on keeps working while their identity data stops leaving the country by default, and you keep Clerk for the markets where it already serves you.
Then deliver: the China-facing app that presents that login is a public service in the mainland, so it carries an ICP filing (备案) duty and needs compliant, in-country delivery. 21YunBox delivers it in-country — the 21YunBox Optimizer — in front of what you already run, with no rebuild and no re-platform. The result is a China-facing sign-in that runs legally and compliantly for your users in China. What we never do — and what no one lawfully can — is hand you a way around China’s data-export rules or around any network restriction: we localize what must stay in the country and deliver in-country, and we never move personal information out of China by stealth.
Related reading:
- Cross-border data transfers under PIPL
- China’s data-export security assessment
- China’s Cybersecurity Law (data localization, Article 39)
- How to get an ICP filing for China
