How to fix a SCORM package blocked in Safari or Chrome

A SCORM package that shows a blank frame or will not launch in Safari may be blocked by a cookie rule rather than broken. When the course plays inside a frame served from a different domain than the LMS page around it, its cookies are third-party, and Safari's engine, WebKit, says its tracking prevention "by default blocks all third-party cookies". In Chrome, check 3 other causes first: a file served over HTTP inside an HTTPS page, a pop up blocker stopping a course set to open in a new window, and a cookie set without SameSite=None and Secure.

A learner on a Mac can run 1 check to see whether Safari's cross-site tracking setting is involved. The lasting fix belongs to whoever hosts the course: serve every file over HTTPS and make the course work without a third-party cookie.

Why does Safari block a SCORM package?

Safari blocks the package when the course's cookies count as third-party. WebKit calls its tracking prevention Intelligent Tracking Prevention (ITP), and its page says "ITP by default blocks all third-party cookies" and adds: "There are no exceptions to this blocking."

A course is third-party when it is cross-site content "embedded in an <iframe>", in MDN's words. Moodle puts SCORM in a frame too: "Moodle uses iFrames for deploying SCORM". The frame is only half of MDN's definition; the content in it also has to be cross-site.

SCORM Cloud's guide gives an example: an app on yourdomain.com frames a course from cloud.scorm.com, and "the browser treats the SCORM Cloud session cookie as 'third-party.'" If that cookie is blocked, "the course will fail to launch or track progress."

Because there is a risk of exposing data intended for one site to other sites, browsers commonly block sending unpartitioned third-party cookies in requests, and don't allow access to them in embedded contexts.

MDN Web Docs, "Storage Access API"

If your learners are on iPhones or iPads, WebKit's default cookie policy covers iOS and iPadOS as well as macOS, and a third party "first has to become first-party and set its initial cookie(s) there" before it can use cookies at all.

WebKit names only 2 ways back in: "the Storage Access API and the temporary compatibility fix for popups". The page does not explain the second, and this article does not say what it does.

Why does a SCORM package not work in Chrome?

3 more causes turn up in Chrome. Of the pages read, only MDN ties one of them, the SameSite default, to Chrome by name. The web.dev page says most browsers block mixed content, and Moodle's pop up warning names no browser.

Mixed content. If your LMS loads over HTTPS and the course, or a script or frame inside it, loads over HTTP, that part is active mixed content. Active mixed content "includes scripts, stylesheets, iframes, and any other code the browser can download and execute". "Most browsers already block this type of content by default to protect users."

Pop ups. When your LMS opens the course in a new window, "students need to ensure pop ups are enabled", Moodle's settings page warns. SCORM Cloud launches courses "in a new browser window (popup)" by default.

SameSite. A cookie with no SameSite attribute is treated "as if it were set to SameSite=Lax". For embedded content, MDN's notes on Chrome say "Cookies must have SameSite=None explicitly set on them, because the default value for Chrome is SameSite=Lax". A None cookie must also be Secure "for the browser to accept them".

None of the pages read states Chrome's default for third-party cookies on 9 October 2026. web.dev's SameSite page says access to third-party cookies "may be impacted by user settings, browser restrictions or Enterprise policy". SCORM Cloud's February 2026 guide lists Chrome with Safari and Edge among browsers that "increasingly block third-party cookies".

How do you tell which block you hit?

Start with the browser's own report. Chromium-based browsers list blocked content in the Issues tab of developer tools, and "Firefox and Safari log messages in the console". Open developer tools on the course page, relaunch, and read the report before you change anything.

Then compare the domain in your address bar with the domain the course frame loads from. If they differ, the course may be cross-site content in MDN's sense, and the third-party cookie rules may apply. The pages read do not say whether 2 addresses under 1 parent domain count as 1 site.

If your course runs when opened in its own tab and fails in the frame, that points the same way: MDN contrasts embedded content with a "first-party context (i.e., when loaded directly in a browser tab)".

The third and fourth columns are this page's reading of the sources, not any browser maker's statement.

A blank page right after you upload a large package is a different fault. Moodle's FAQ names a missing PHP zip library as the likely cause; How to upload a SCORM package to Moodle covers it.

Who can fix the block, and how?

What can the learner do right now?

On a Mac, run 1 test in Safari: choose Safari > Settings, click Privacy, and find "Prevent cross-site tracking". With the box selected, Apple says, third-party providers you have not visited and interacted with as a first-party website have "their cookies and website data" deleted. Clear the box and relaunch the course; if it now plays, you have found your block.

Then select the box again. Apple's page explains how to select the setting, not how to clear it, and does not say that clearing it lifts a block WebKit describes as having "no exceptions". This article read only the Mac guide, so it gives no iPhone or iPad path.

3 more checks you can make alone:

• If the course opens in a new window, allow pop ups for your LMS's address.
• Make sure JavaScript is on; Moodle's FAQ says "SCORM requires JavaScript".
• If the browser asks you to grant the course access, allow it. MDN says Safari and Chrome prompt embedded content that has not had storage access before, when the content asks.

On a work laptop you may not be allowed to change any of this; web.dev lists "Enterprise policy" among what can affect third-party cookie access. Send IT the browser, the device and the exact text from the Issues tab or console.

What can the LMS admin fix?

Find where the course plays from, then remove the cross-site part or the HTTP part, so no learner has to touch a setting.

One reading of MDN's definition: a zip uploaded into the LMS and played from the LMS's own domain is not cross-site content, so the third-party cookie rules would not apply to it. No page read for this article says where any LMS serves an uploaded package from. An LMS can serve its files from a separate domain, so check the address of your course frame first.

A linked package is different: Moodle's "Enable external package type" "presents a text field to paste a URL to a remote imsmanifest.xml". A remote manifest, a content server or a hosted player can put your course on another domain, the setup in SCORM Cloud's guide.

• Move everything to HTTPS. "Change insecure content requests to secure content", for the LMS and every file the course loads.
• Use a cookieless launch if your host has one. SCORM Cloud's Content Vault "authorizes the learner using a short-lived token and IP address validation instead of a traditional cookie", switched on with a launchAuth parameter or at the application level. For other hosts, check their own documentation.
• Pick the window on purpose. Moodle's Display package offers "current or new window". A new window runs into pop up blockers. A frame brings the iOS scrolling problem from Moodle's FAQ, plus the third-party rules if the course in it comes from another domain. Test both.

What must the course author or host change?

Make the course work without a third-party cookie, or ask for one the way browsers allow.

• Set cookies for embedded use. SameSite=None sends a cookie "in all contexts", and it must be Secure too "for the browser to accept them". In Chrome, set None explicitly.
• Ask for storage access on a click. document.requestStorageAccess() "returns a Promise that resolves if the access was granted, and rejects if access was denied", and the request "must be associated with a user gesture (transient activation) such as a tap or click". Put the call behind your Start button, not in the page load. Grants expire: Safari phases them out after "30 days of browser usage passed without user interaction".
• Remove every hard-coded http:// address from the package, scripts, stylesheets and frames first.

How do you test the fix before learners see it?

1. In the frame's console, run await document.hasStorageAccess(). It resolves with "a boolean value indicating whether the document has access to third-party cookies".
2. In Moodle, turn on Activate API debug and tracing. "Red lines in the debugging log means there was an error in the communication through the API."
3. Finish the course, close it and open it again. Check that the course resumed, then open the activity's SCORM report for your attempt and compare it with the debugging log.

How do you find and fix the block yourself?

You need Safari on a Mac, Chrome, 1 iPhone or iPad and the developer tools built into both browsers. You also need a test learner account, plus edit rights on the activity or the name of whoever has them. Nothing to buy.

1. Reproduce it in 2 browsers. Note which fail, and on which device.
2. Read the browser's report. Issues tab in Chrome, console in Safari.
3. Compare the domains of the address bar and the course frame.
4. Clear Safari's box for 1 test, relaunch, then select it again.
5. Check the window setting and pop ups.
6. Send the fix to the right person with the browser, the 2 domains and the report text: HTTPS and the window setting to the admin; SameSite, storage access or a cookieless launch to the host or author.

Steps 1 to 3 take about 20 minutes, steps 4 and 5 about 10, and step 6 depends on the host. These are working estimates for 1 course, not vendor figures.

Which browser fix mistakes cost the most?

1. Calling the Safari workaround the fix. "Prevent cross-site tracking" is a setting in each learner's own Safari, and on a managed device the learner may not be able to change it. Every new learner opens the same ticket.
2. Testing only in Chrome on your own machine. WebKit blocks third-party cookies by default.

A SCORM course that won't complete? Send it to us. We fix one course free for companies, or tell you why it fails, within 48 hours. See the free SCORM fix.

Other questions about SCORM in Safari and Chrome

Does Safari block all third-party cookies?

WebKit says "ITP by default blocks all third-party cookies" with "no exceptions"; access comes back only through the Storage Access API and a temporary compatibility fix for popups.

Why does my SCORM course work in Chrome but not in Safari?

The pages read for this article point to 1 difference: WebKit blocks third-party cookies by default, and none of them states Chrome's default as of 9 October 2026. If your course plays in a frame from another domain, that difference could be why.

Does SCORM 1.2 or SCORM 2004 make a difference?

None of the pages read for this article ties the block to the SCORM version; the causes they describe are domains, HTTPS, windows and cookies. SCORM 1.2 vs SCORM 2004 covers that choice.