What is SCORM? A plain-language guide to how packages, manifests, and the runtime actually work

SCORM is a zip file with rules. This guide explains what is inside the package, what the LMS does with it, what the course sends back, and where SCORM 1.2 and 2004 differ.

What SCORM is, in one paragraph

SCORM — the Sharable Content Object Reference Model — is a set of rules that lets a course built by one tool run inside a learning management system built by another. It was published by ADL, a US Department of Defense initiative, first as SCORM 1.2 in 2001 and then as SCORM 2004 in four editions. A SCORM course is a zip file. The LMS unzips it, reads a manifest that lists the pages and the order they run in, launches the content in a browser frame, and listens for a small number of JavaScript calls that report progress, score, and completion. That is the whole thing. Everything else is detail about the manifest and the data model.

What is inside a SCORM package

Unzip any SCORM package and you will find three kinds of file.

  • imsmanifest.xml at the root. This is mandatory and it is the file the LMS reads first. It declares the organisation of the course (a tree of items), the resources each item points to (HTML files, images, scripts), and the schema version the package claims to follow.
  • The content itself — HTML, CSS, JavaScript, media. The LMS never interprets this; it just serves it in an iframe or a new window.
  • Schema definition files (.xsd) that describe the manifest format. Strict LMSs validate the manifest against them; most ignore them.

Each launchable unit in the manifest is a Sharable Content Object, or SCO. A SCO is simply an HTML page that knows how to find the SCORM API and talk to it. A package can contain one SCO (the common case for converted PowerPoint or PDF content) or many (one per module), and the manifest decides which is which.

Most import failures are manifest failures. A typo in a resource href, a missing identifier, or a 2004 manifest declared with 1.2 namespaces will stop an import before any learner sees the course. SCORM Central validates the manifest against the declared schema on every build, which catches most of these before upload.

The runtime conversation

When a learner launches a SCO, the content's JavaScript searches up through the window hierarchy for an object the LMS has placed there: API for SCORM 1.2 or API_1484_11 for SCORM 2004. Once it finds it, the conversation follows a fixed shape:

Initialize("")                        → "true"
GetValue("cmi.learner_name")          → "Dana Whitfield"
GetValue("cmi.entry")                 → "resume"
SetValue("cmi.location", "sec-05")    → "true"
Commit("")                            → "true"
SetValue("cmi.score.scaled", "0.84")  → "true"
SetValue("cmi.success_status","passed")
SetValue("cmi.completion_status","completed")
Terminate("")                         → "true"

Every value is a string. The content reads what it needs (the learner's name, where they left off), writes what it has learned (bookmark, score, status), asks the LMS to persist it with Commit, and closes the session with Terminate. The LMS stores whatever arrived. Nothing is pushed from the LMS to the content after launch, and the LMS has no idea what happened inside the page unless the page told it.

This is why two courses that look identical can report completely differently. One sets cmi.completion_status when the last page is viewed; another only sets it after a quiz. One calls Commit after every interaction; another only at exit — and loses everything if the learner closes the tab. The runtime log is where you find out which one you have.

SCORM 1.2 vs SCORM 2004

The two versions are not compatible with each other, but almost every LMS imports both. The practical differences:

ConcernSCORM 1.2SCORM 2004 (2nd–4th Ed.)
StatusOne field, cmi.core.lesson_status: passed, completed, failed, incomplete, browsed, not attemptedTwo fields: cmi.completion_status and cmi.success_status — a learner can be completed and failed
Scorecmi.core.score.raw, min, maxAdds cmi.score.scaled (0–1), which the LMS uses for rollup
Bookmark / statecmi.suspend_data capped at 4,096 charactersCap raised to 64,000 characters
SequencingNone — the content decides what comes nextManifest can define rules, prerequisites, rollup, and navigation controls
InteractionsWrite-only; the LMS may discard themRead/write, with typed responses and pattern matching

Which one to ship depends on the destination, not on which is newer. SCORM 1.2 is the safer import on older or locked-down platforms and remains the most common request. SCORM 2004 is the right choice when you need completion and success reported separately, when a single-page course stores more than 4 KB of state, or when you want the LMS rather than your content to enforce module order. SCORM Central builds either from the same source, so the decision can be made per course and revisited later. Read SCORM 1.2 vs 2004: which one to build for the decision rules.

What SCORM cannot do

Knowing the limits avoids a lot of disappointment.

  • It has no concept of a learner outside one LMS. There is no cross-platform identity and no central record.
  • It reports a handful of values. If you want to know which video chapter a learner rewatched or which branch of a scenario they chose, SCORM 1.2 will not store it and SCORM 2004 stores it only as interactions most LMS reports never surface.
  • It requires a browser and a live LMS session. There is no offline mode in the specification.
  • It does not protect content. The zip is the course. Anyone who can download it can open it.
  • Updating a course means re-importing the zip on every LMS that has it — unless the package is a thin launcher that points at a hosted copy, which is what dispatch is for.

When to use something else

If the destination is an LMS and the reporting you need is pass/fail, score, and completion, SCORM is the right answer and will be for years. If you need detailed activity data, or the content lives outside an LMS (a mobile app, a simulator, a web portal), look at xAPI, which sends statements to a learning record store instead of values to an LMS. If you want xAPI-level data but still need an importable package, cmi5 wraps xAPI in a zip the LMS can launch. The comparison in SCORM vs cmi5 vs xAPI walks through the choice.

Whatever you choose, start with a file you already have and look at what the build reports. The manifest, the runtime log, and the conformance report tell you more in five minutes than the specification does in fifty pages.

Keep reading

How-to4 min Convert SCORM to video or PowerPoint? Can you convert SCORM to MP4, HTML5 or PowerPoint? What is inside a package, the routes that work, and what you lose with each one. Explainer4 min Does your LMS support xAPI? How to check What xAPI LMS support really means: launching xAPI content, a built-in LRS, or forwarding statements. The questions to ask and a quick test to run. Explainer4 min LMS vs LRS: what is the difference? LMS vs LRS: an LMS runs courses and learners; an LRS stores xAPI statements. Why SCORM does not use an LRS, and when you need both.

Start with one file.

Upload something you already have and see it as a package, with the conformance report and the runtime log alongside it.

→ upload  handbook.pdf
  parsing … 14 sections
  building manifest …
  validating … 0 errors, 2 notes
✓ handbook-scorm2004.zip
✓ preview link ready