The short answer
SCORM vs xAPI is a comparison between two different kinds of thing. SCORM is a zip package launched inside an LMS that reports fixed values through a JavaScript API. xAPI is a statement format — actor, verb, object — sent over HTTP to a Learning Record Store from anywhere. xAPI does not replace SCORM; the two run side by side.
Most of the confusion comes from treating this as "old standard, new standard". The rest of this article walks through what each one actually does at runtime, so the choice stops being about which name sounds more current.
What SCORM is, and what xAPI is
SCORM — the Sharable Content Object Reference Model — bundles three things. First, a package: a zip with imsmanifest.xml at the root listing the launchable pages and the order they run in. Second, a runtime: the content's JavaScript finds an API object the LMS placed in the browser window and calls Initialize, GetValue, SetValue, Commit and Terminate against a fixed data model of score, status, bookmark and suspend data. Third, in SCORM 2004 only, sequencing rules in the manifest that let the LMS control which activity comes next. Every part of this assumes an LMS: something has to unzip the package, serve the pages, provide the API object and store what comes back.
xAPI — the Experience API, originally Project Tin Can — defines none of those. It defines a statement: a JSON document saying that an actor did a verb to an object, optionally with a result and context. It defines a Learning Record Store, the service that accepts statements over HTTP and lets you query them back. It has no package format, no manifest, no launch method and no concept of a course. A statement can come from a browser page, a mobile app, a simulator or a server-side job, as long as it can make an authenticated HTTP request. The plain-language version is in What is xAPI?.
| Concern | SCORM | xAPI |
|---|---|---|
| What it specifies | Package, runtime API, data model, sequencing (2004) | Statement format, LRS, HTTP API |
| Where content runs | Inside an LMS, in a browser frame or window | Anywhere that can send HTTP |
| How content reports | JavaScript calls to an API object in the window | HTTP POST of a statement to an LRS endpoint |
| What it records | A fixed data model: status, score, location, suspend data, interactions | Any actor–verb–object statement |
| Package / import | Yes — the zip is the course | No package defined by the specification |
| Who stores the data | The LMS that launched the attempt | An LRS, which may be inside or outside the LMS |
Does xAPI replace SCORM?
No, and it was not designed to. ADL commissioned xAPI to record learning that happens outside the SCORM model — outside a browser, outside an LMS, across more than one system. It did that by leaving out the parts of SCORM that tie content to one LMS, which is also why it cannot do SCORM's job. An administrator with a zip file to import still needs a package format and a launch method, and xAPI provides neither.
The piece that fills that gap is cmi5. cmi5 is an ADL specification that defines a package (cmi5.xml listing assignable units), a launch handshake between the LMS and the content, and a required set of xAPI statements for launched, initialized, completed, passed, failed and terminated. So the realistic successor to a SCORM package inside an LMS is a cmi5 package, which carries xAPI statements to an LRS. The three-way comparison in SCORM vs cmi5 vs xAPI covers when that matters; the point here is that "xAPI replaces SCORM" is only true once you add cmi5, and only where the LMS supports it.
Where the data goes
This is the difference that affects reporting, so it is worth being concrete.
In SCORM, the data lives in the LMS, attached to one learner's attempt on one course. The runtime data model is fixed: cmi.core.lesson_status and cmi.core.score.raw in 1.2, cmi.completion_status, cmi.success_status and cmi.score.scaled in 2004, plus the bookmark, suspend data and, if the LMS keeps them, interactions. Nothing outside that model is stored, and nothing is stored unless the content calls SetValue and then Commit. If you later migrate to another LMS, the attempt records go with the old platform's export, in whatever shape it chooses.
SCORM 2004, inside the LMS session:
SetValue("cmi.score.scaled", "0.84") → "true"
SetValue("cmi.success_status", "passed") → "true"
SetValue("cmi.completion_status","completed") → "true"
Commit("") → "true"
xAPI, as an HTTP request to an LRS:
POST /xapi/statements
{ "actor": { "mbox": "mailto:dana@example.org" },
"verb": { "id": "http://adlnet.gov/expapi/verbs/passed" },
"object": { "id": "https://example.org/courses/fire-safety" },
"result": { "score": { "scaled": 0.84 }, "success": true } }
In xAPI, the data lives in the LRS as a stream of immutable statements, each with its own id. The same learner can appear in statements from the LMS, a mobile app and a classroom sign-in, and a query against the LRS returns all of them together. Because the LRS is a separate component — it may be built into the LMS or run on its own — the record can outlive any one platform. What xAPI does not give you is a single "status" field: completion is whatever your reports decide it is, based on which verbs they look for. That freedom is why xAPI reporting needs more design work than reading a SCORM gradebook. SCORM and an LRS explains how the two storage models meet.
Can SCORM and xAPI work together?
Yes, and in practice this is common. They are compatible in the sense that they do not interfere with each other, not in the sense that one understands the other. Three arrangements come up repeatedly.
- A SCORM course that also sends xAPI. The content talks to the LMS through the SCORM API for status and score, and separately POSTs statements to an LRS for detail the data model cannot hold — which scenario branch was chosen, how long a video was watched, which help panel was opened. The LMS never sees the statements; the LRS never sees the SCORM calls. The content needs the LRS endpoint and credentials, which the SCORM launch does not supply, so they are usually baked into the package or fetched from a configuration file.
- An LMS that translates SCORM into xAPI. Some platforms take the SCORM runtime calls they receive and emit equivalent statements to an LRS, so a SCORM course appears in xAPI reports unchanged. The statements are only as rich as the SCORM data model, and the mapping is the platform's choice, so check what it emits before relying on it.
- cmi5 as the bridge. A cmi5 package is imported like SCORM, launched by the LMS, and reports exclusively through xAPI. If the goal is to keep the LMS import workflow and move the data to an LRS, this is the arrangement the specifications intend.
What does not work is expecting an LMS with no LRS to accept xAPI statements, or expecting an LRS to launch a SCORM package. Each side only speaks its own protocol. In a mixed course, SCORM's Commit and Terminate still decide what the LMS records, so a course that is careful about its statements but sloppy about its commits will have rich analytics and missing completions.
Which one to pick
Decide by destination and by what the data must answer.
- The course will be imported into an LMS, and the reporting you need is completion, pass/fail and a score: SCORM. It is supported by effectively every LMS, and SCORM 2004 covers the cases where 1.2 is too small.
- The learning happens outside an LMS — an app, a simulator, a portal, a classroom — or you need to combine records from several systems: xAPI, with an LRS to receive it, and a launch and credentials you plan yourself.
- You want xAPI-level data but the LMS import workflow has to stay: cmi5, provided the destination LMS supports it. Where it does not, a SCORM package that also sends statements is the pragmatic fallback.
Whichever you choose, the proof is what the destination actually records after a real launch — the runtime calls for SCORM, the statements that reach the LRS for xAPI — not the export menu label.
Where SCORM Central fits
SCORM Central turns PowerPoint, PDF, and video files into SCORM 1.2 or SCORM 2004 4th Edition packages you can edit in its course builder, and its free tester shows the manifest checks and every runtime call a package makes before an LMS sees it. See how it works, or test a package free.