SCORM vs. xAPI: which eLearning standard your training actually needs
The most common misconception about SCORM and xAPI is that xAPI is "SCORM 3" — the newer version you should upgrade to. It isn't. They answer different questions. SCORM answers "did this person complete this module in the LMS, and what did they score?" xAPI answers "what learning-related things did this person do, anywhere?"
Most corporate training programmes need the first question answered reliably far more than they need the second answered ambitiously. Here's what each standard actually records, where each one breaks down, and a decision rule you can apply in one meeting.
What SCORM records
SCORM (2001, with the 2004 revision following) is a packaging-and-tracking standard for content that runs inside an LMS, in a browser. The module and the LMS talk through a JavaScript API using a fixed vocabulary — completion status, pass/fail, score, session time, a resume bookmark. If the concept isn't in the data model, it can't be recorded. (If you want the ground-up explanation, start with What is SCORM?)
That fixed vocabulary is a feature, not a limitation. Because every LMS implements the same small contract, a SCORM 1.2 package built today will launch and report in essentially any LMS your company is likely to buy. Twenty-five years of compatibility is not something to discard casually.
What xAPI records
xAPI (the Experience API, released in 2013 and still occasionally called by its project name, Tin Can) throws away the fixed vocabulary. Instead, anything that can make an HTTP request can send a statement — a JSON record in the shape actor–verb–object: "Priya completed Fire Safety Module 3", "Tomasz attempted the ladder-logic simulation", "Ana attended the Q3 sales kick-off". Statements go to a Learning Record Store (LRS), a database built to receive and query them.
Three consequences follow, and they're the whole point of xAPI:
- No browser required. A mobile app, a VR headset, a flight simulator, or a plain server-side script can all send statements. SCORM physically cannot see any of these.
- No LMS required. The LRS is independent. Learning that happens outside your LMS — coaching sessions, on-the-job checklists, conference attendance — can land in the same store as your eLearning data.
- Arbitrary granularity. SCORM gives you one score per SCO. xAPI can record every question, every attempt, every video pause, if you choose to send it.
Where SCORM breaks down
- Blended programmes. The workshop, the shadowing day, the practical assessment — none of it exists as far as SCORM is concerned. Someone ends up marking attendance in a spreadsheet and hand-keying completions into the LMS.
- Session fragility. SCORM reports through a live browser session; close the window at the wrong moment and data can be lost. xAPI statements are fire-and-forget HTTP calls, individually durable.
- Analytics depth. If you want to know which questioneveryone fails, or how performance correlates across modules, SCORM's one-score-per-module model forces you to squint. This matters when you get serious about measuring whether training actually worked.
Where xAPI breaks down
The honest part of this comparison is that xAPI's failure modes are organisational rather than technical.
- An LRS is not an LMS.xAPI deliberately says nothing about enrolment, course launch, or completion rules. Buy an LRS and you have a database of statements — you still need something to assign training, launch it, and decide what "done" means.
- Statement soup.Because senders can phrase statements however they like, two tools will describe the same event differently. Without an agreed vocabulary up front, you accumulate data you can't aggregate. Teams routinely spend more time governing statement design than they expected — plan for it.
- Patchier LMS support. Plenty of LMSes accept an xAPI package but track it with less fidelity than their SCORM pipeline, which has had two decades of debugging.
The bridge: cmi5
There is a middle path worth knowing about. cmi5 is a profile of xAPI — a rulebook layered on top — that puts back the pieces xAPI left out for LMS use: how a course is packaged, how the LMS launches it, how the session authenticates, and which statements mark completion and pass/fail. In effect, cmi5 gives you SCORM-style launch-and-track semantics with xAPI's richer data underneath. Adoption is growing but still trails both parents; check your specific LMS before betting a programme on it.
How to choose, in one meeting
- Compliance, onboarding, certification inside one LMS: SCORM 1.2. Maximum compatibility, simplest debugging, exactly the record auditors want.
- Your LMS mandates 2004 features (separate completion and success status, sequencing): SCORM 2004 — the trade-offs are covered in our 1.2 vs. 2004 field note.
- Learning happens across systems, devices, or the physical world, and you have (or will fund) an LRS: xAPI, with a written statement vocabulary before the first module ships.
- Genuinely unsure: ship SCORM now. Nothing about publishing SCORM today prevents publishing xAPI tomorrow — the expensive asset is the content, not the wrapper.
That last point is worth designing for: keep your source material in an editable form and treat the packaging as an export decision. Mltitude's eLearning generator takes exactly this stance — one module, exportable as SCORM 1.2, SCORM 2004, or xAPI, so the standards question stops being a build decision and becomes a publish-time dropdown. You can try it free without an account.