'Invalid publishable key' or Backend API 401: publishable key and secret key are swapped

Not specified by the original author.

TL;DR: The frontend refuses to load Clerk, or backend calls return 401. One of the two keys is sitting in the other's slot. Confirm the cause 1. Both keys must come from the SAME instance.

The fix

1. Publishable keys start with pk and belong on the frontend: ClerkProvider and NEXTPUBLIC_ variables. They are safe to expose.
2. Secret keys start with sk and belong ONLY on the backend, for createClerkClient and direct Backend API calls. A secret key in a NEXTPUBLIC_ variable ships it to every browser.
3. If the frontend complains: you likely pasted a secret key into the publishable slot, or there is a typo or stray whitespace.
4. If the Backend API 401s: you likely passed the publishable key where the secret key belongs.
5. Both keys must come from the SAME instance. A pktest key paired with an sklive key never works.
6. Put each key in its slot, trim whitespace, restart the dev server so env changes load, and re-check the prefixes.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: 'Invalid publishable key' or Backend API 401.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Not pinned to a specific version; follows current 'Invalid behavior.

Verified against Clerk deployment docs 2026-09-26: the publishable key (pktest in development, pklive in production) is passed to ClerkProvider during initialization; the secret key (sktest/sklive) is used to access the Backend API. Forgetting to switch keys per environment is the documented common mistake.