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"12. In Chrome, check 3 other causes first: a file served over HTTP inside an HTTPS page3, a pop up blocker stopping a course set to open in a new window4, and a cookie set without SameSite=None and Secure56.

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

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."1

A course is third-party when it is cross-site content "embedded in an <iframe>", in MDN's words6. Moodle puts SCORM in a frame too: "Moodle uses iFrames for deploying SCORM"8. 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."2

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"6

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 all1.

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

Why does Chrome block a SCORM package?

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."3

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

SameSite. A cookie with no SameSite attribute is treated "as if it were set to SameSite=Lax"5. 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"6. A None cookie must also be Secure "for the browser to accept them"5.

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"5. SCORM Cloud's February 2026 guide lists Chrome with Safari and Edge among browsers that "increasingly block third-party cookies"2.

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"3. 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 apply6. 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)"6.

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

SymptomBrowserLikely causeWho can fix itSource
Blank frame or no launch on a Mac, iPhone or iPadSafariCourse framed from another domain; third-party cookies blockedLearner for 1 test; admin or host for goodWebKit1; SCORM Cloud2
Launches, but progress or completion never savesAny that blocks third-party cookiesThe host's session cookie is third-partyAdmin and content hostSCORM Cloud2
Blank frame; Issues tab or console reports mixed contentChrome and othersAn HTTP file inside an HTTPS pageAdmin or authorweb.dev3
Nothing opens when you start the courseAnyNew window launch, pop ups blockedLearner; admin can switch the windowMoodle settings4
Course framed from another domain loses its sessionChromeCookie without SameSite=None, or None without SecureContent hostweb.dev5; MDN6
Nothing loads in any browserAnyJavaScript offLearner or ITMoodle FAQ8

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 cause8; How to upload a SCORM package to Moodle covers it.

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"7. 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" deleted7. 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"71. 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 address4.
  • Make sure JavaScript is on; Moodle's FAQ says "SCORM requires JavaScript"8.
  • 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 asks6.

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 access5. 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 it6. 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"4. A remote manifest, a content server or a hosted player can put your course on another domain, the setup in SCORM Cloud's guide2.

  • Move everything to HTTPS. "Change insecure content requests to secure content"3, 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 level2. For other hosts, check their own documentation.
  • Pick the window on purpose. Moodle's Display package offers "current or new window"4. A new window runs into pop up blockers. A frame brings the iOS scrolling problem from Moodle's FAQ8, plus the third-party rules if the course in it comes from another domain6. Test both.

What does the course author or content host have to 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"5. In Chrome, set None explicitly6.
  • 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"6. 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"6.
  • Remove every hard-coded http:// address from the package, scripts, stylesheets and frames first3.

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"6.
  2. In Moodle, turn on Activate API debug and tracing4. "Red lines in the debugging log means there was an error in the communication through the API."8
  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 log8.

How to do it 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 Safari3.
  3. Compare the domains of the address bar and the course frame6.
  4. Clear Safari's box for 1 test, relaunch, then select it again7.
  5. Check the window setting and pop ups4.
  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 admin34; SameSite, storage access or a cookieless launch to the host or author562.

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.

The mistakes that cost the most

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

Questions people also ask

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 popups1.

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 default1, 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 why2.

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.

  1. WebKit, "Tracking Prevention in WebKit", undated, read 9 October 2026. https://webkit.org/tracking-prevention/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  2. Rustici Software, SCORM Cloud support, "SCORM Cloud: How to Launch Courses in an iFrame (Embedded Launch)", updated 19 February 2026, read 9 October 2026. https://support.scorm.com/hc/en-us/articles/46727466405787-SCORM-Cloud-How-to-Launch-Courses-in-an-iFrame-Embedded-Launch ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  3. web.dev, Jo-el van Bergen and Rachel Andrew, "What is mixed content?", last updated 7 September 2019, read 9 October 2026. https://web.dev/articles/what-is-mixed-content ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  4. Moodle Docs 5.3, "SCORM settings", last edited 14 August 2025, read 9 October 2026. https://docs.moodle.org/503/en/SCORM_settings ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  5. web.dev, Rowan Merewood, "SameSite cookies explained", last updated 7 May 2019, read 9 October 2026. https://web.dev/articles/samesite-cookies-explained ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  6. MDN Web Docs, "Storage Access API", last modified 4 September 2026, read 9 October 2026. https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  7. Apple Support, Safari User Guide, "Prevent cross-site tracking in Safari on Mac", undated, read 9 October 2026. https://support.apple.com/guide/safari/prevent-cross-site-tracking-sfri40732/mac ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  8. Moodle Docs 5.3, "SCORM FAQ", last edited 16 April 2024, read 9 October 2026. https://docs.moodle.org/503/en/SCORM_FAQ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎