How to embed a SCORM course in plain HTML.

No WordPress. No page builder. Just a folder of HTML you push to a static host, or a docs portal your team hand-maintains, and a SCORM module that needs to live on one of its pages. Good news: this is the easiest embed there is. You own every line of markup, Training OS runs the package, and the whole job is one tag. The traps are not in the HTML — they're in the headers and the build step.

I've wired hosted modules into Jekyll sites, Hugo docs, a hand-rolled intranet, and one terrifying 2009-era SharePoint page. The snippet was identical every time. What broke was always the same short list: a Content-Security-Policy header, a markdown processor quietly escaping the iframe, or someone testing while logged in. Let's skip those afternoons.

Get the launch URL working in a bare browser tab first. If it doesn't play there, no amount of HTML will fix it.— the rule that saves you a debugging session

Get the launch URL working first.

Before you write a single tag, paste your Training OS URL straight into the address bar and run the module. Debugging is dramatically faster when the player is known-good in isolation — you want to know the course works beforeyou add your own page, your own headers, and your own build pipeline to the list of suspects. Training OS extracts the package and serves the runtime over HTTPS with a stable launch URL; your page's only job is to send people to it.

If you're still deciding where the package should live in the first place, start with where to host a SCORM file and come back once you have a URL that plays.

Two things to check first.

There are exactly two prerequisites, and skipping either is the cause of most "it works on my machine" tickets.

1. Serve the parent page over HTTPS.

If your Training OS launch URL is HTTPS (it is), the page embedding it must be HTTPS too. An HTTP page loading an HTTPS resource trips mixed-content protection — browsers block the script or the frame in predictable, silent ways. Most static hosts give you HTTPS for free; turn it on before you embed.

2. Know whether your deployment target injects CSP.

Plenty of internal portals and corporate hosts add a Content-Security-Policyheader that restricts which origins an iframe may load. If yours does, an iframe to Training OS will render as nothing until someone allows the domain. On a public static host this is usually a non-issue; on an intranet, find out early — you may need IT to whitelist the Training OS origin, and that's a request with a lead time.

The two snippets, ranked.

Once the URL plays in a bare tab, you have two ways to put it on the page. Ranked by how rarely they break:

<a
  href="https://app.trainingos.com/m/your-module"
  target="_blank"
  rel="noopener noreferrer"
>Launch the module</a>

<iframe
  src="https://app.trainingos.com/m/your-module"
  width="100%"  height="760"
  allow="fullscreen"
  title="Onboarding module — interactive"
></iframe>

CSP and the blank-box problem.

When an iframe renders as an empty rectangle, it is almost never the module. It's the page around it. Three culprits, in the order I actually hit them:

1. A frame-blocking header on the parent page.

Open the console on the live page. A frame-ancestors violation from a Content-Security-Policy header, or a legacy X-Frame-Optionsheader, will tell you exactly why the browser refused to paint the frame. Allow the Training OS origin in that policy — or, if you can't edit headers, use the link and move on.

2. The build step ate your iframe.

Static site generators run your content through a markdown processor that escapes or strips raw HTML by default. Your iframe looks perfect in the source file and is simply gone in the built page. Wrap it in whatever raw-HTML escape hatch your generator provides — an MDX block, a shortcode, a passthrough fence — so it survives the build.

3. Strict privacy settings break the session.

Test in Chrome and Safari with third-party cookies restricted. Some learners run hardened privacy settings that interfere with session state inside a cross-site iframe — playback starts, but resume or completion quietly fails. If your audience skews privacy-conscious, the link pattern is the safer default.

Before you commit and deploy.

Validate in staging, then run this once from a logged-out incognito window on production:

• The link or iframe loads the running module — not a download prompt or a blank box.
• The parent page is HTTPS, with no mixed-content warning in the console.
• If you used an iframe, your generator did not escape it — view source and confirm the raw tag survived.
• Completion, score, and resume behave the way the package was published to behave.
• It looks right on a phone — narrow layouts crush short iframes, so bump the height or fall back to the link.

That's the whole job. For the CMS-flavored version of this, see embedding SCORM in WordPress; if completion is the thing misbehaving, the completion-status field is where to look next.

Frequently asked questions.