Skip to main content
EpisBox works fine in local development — but only if your page is served over http:// or https://. Opening your HTML file directly in the browser (double-clicking it, or a file:///Users/you/project/index.html-style URL) will silently fail to load the embed.

​
Why file:// doesn’t work

EpisBox mounts an <iframe> from embed.pastpaperlm.com into your page. Browsers decide whether an iframe is allowed to load inside a given parent page using the Content-Security-Policy: frame-ancestors header that embed.pastpaperlm.com sends back. That header is set to frame-ancestors * — as permissive as CSP allows. But per the CSP spec, the * source expression explicitly excludes pages with an opaque origin — and a page loaded via file:// always has an opaque origin. So the browser refuses the embed, even though the policy is “allow everyone.” This isn’t an EpisBox bug or a bug in your code — it’s how every browser implements the spec.
This has nothing to do with HTTPS. http://localhost:3000, http://localhost:5173, and http://192.168.1.5:8080 all work identically — any of them gives your page a real (non-opaque) origin. The only thing that breaks is file://.

​
Get a local server running

Pick whatever’s already in your stack — nothing here is EpisBox-specific, any static file server works.
If your app already runs behind a dev server (React, Vue, Next.js, Vite — anything with an npm run dev), you’re already covered. This page only matters for plain static HTML pages like the SPA integration path — the kind you’d otherwise be tempted to just open from disk.

​
No domain registration required for local testing

Your clientId isn’t checked against a registered domain today (see Security) — any string works, from any origin, including localhost. There’s no separate “local dev” clientId or sign-up step. Pick any placeholder string and start building.

​
Still not loading?

If the embed is still blank after switching off file://, see Troubleshooting.