SCORM vs xAPI vs cmi5: Which E-Learning Standard Should You Use?

Every authoring tool asks the same question at publish time: SCORM 1.2, SCORM 2004, xAPI or cmi5? Most people pick whatever the last course used. That works until a learner reopens a long compliance module and lands back on slide one, or someone asks for data the LMS never received.

Here is the short answer. Use SCORM when the course has to run in any LMS, including ones you do not control. Use cmi5 for new courses that live in your own LMS, provided your authoring tool and your LMS both support it. Use plain xAPI when the learning happens outside a launched course and you have a Learning Record Store that can actually report on it. The rest of this article explains why, and what to test before you commit.

What a standard actually agrees on

An e-learning standard is a contract between a piece of content and the platform that plays it. It covers three things: how the course is packaged, how the LMS launches it, and how the course reports back. Comparisons usually focus on the third. In our experience the first two cause most of the support tickets.

SCORM: narrow, dated and still the safest export

A SCORM package is a zip file with an imsmanifest.xml at its root. The manifest lists the resources and tells the LMS which file to open. Once the course is running in the browser, it looks for a JavaScript API object that the LMS provides and calls it to read and write values such as status, score and bookmark.

SCORM 1.2 vs SCORM 2004

Both versions are still everywhere, and the differences are practical ones:

• Status. SCORM 1.2 has a single cmi.core.lesson_status field, so the course has to report either "passed" or "completed". SCORM 2004 splits this into completion_status and success_status, which means a learner can be completed and failed at the same time. That split is usually what a compliance team wants to see.
• Resume data. SCORM 1.2 caps cmi.suspend_data at 4,096 characters. Long courses with many slides and variables can hit that ceiling, and the symptom is a learner who loses their place. SCORM 2004 3rd and 4th editions raise the limit to 64,000 characters.
• Sequencing. SCORM 2004 added rules for moving learners between several SCOs inside one package. LMS support for those rules has always been uneven, and plenty of teams avoid multi-SCO packages altogether.

SCORM's weakness is scope. It only knows what happens inside that browser window while the course is open. It cannot record a coaching conversation, a simulator session or a video watched in another tool. The data model is fixed, too: status, score, time, interactions and resume data.

Its strength is reach. Practically every LMS and authoring tool supports it. If you sell content to other organizations, or you honestly do not know which LMS you will be on in three years, SCORM is the export that will still open.

xAPI: flexible data, very few rules

xAPI (also called Tin Can) records learning as statements. Each statement has an actor, a verb and an object, plus optional result and context data. Read aloud, they sound like "Priya completed Forklift Pre-Shift Check" or "Marcus answered question 4 with B". The JSON looks roughly like this:

{
  "actor":  { "mbox": "mailto:priya@example.com", "name": "Priya" },
  "verb":   { "id": "http://adlnet.gov/expapi/verbs/completed" },
  "object": { "id": "https://example.com/activities/forklift-pre-shift" },
  "result": { "completion": true, "duration": "PT12M" }
}

Statements are sent to a Learning Record Store (LRS), which is a database with a standard API. Anything that can make an HTTP request can send one, so xAPI can describe learning SCORM never could: a mobile app, a VR scenario, a checklist signed off on the shop floor, time spent in a product sandbox.

The catch is what the spec leaves out. Plain xAPI does not define how an LMS launches content, how the content receives credentials, or what "complete" means. Each authoring tool fills those gaps its own way. A "Tin Can" export typically ships a tincan.xml file and expects the endpoint and auth details on the launch URL in a particular format. Two xAPI courses from two different tools can behave differently in the same LMS.

The second catch is reporting. Statements are only valuable if something queries and visualizes them. A familiar pattern: a team switches to xAPI, collects a year of statements, then discovers nobody built the report. Before you choose xAPI, write down the question you want answered and name the tool that will answer it.

cmi5: xAPI with the rules put back

cmi5 is an xAPI profile written specifically for content launched from an LMS. It keeps xAPI statements and the LRS, and adds back the parts SCORM got right:

• A defined launch. The LMS opens the content with the LRS endpoint, a fetch URL for a one-time auth token, a registration ID and the activity ID. No credentials are baked into the package.
• A course structure file. cmi5.xml describes the course and its assignable units (AUs), which are the cmi5 equivalent of SCOs.
• Session rules. Each session opens with "initialized" and closes with "terminated", so the LMS can tell a finished session from an abandoned tab.
• moveOn criteria. Each AU declares what counts as done: Passed, Completed, CompletedAndPassed, CompletedOrPassed or NotApplicable. The LMS applies that rule instead of guessing.

The result is predictable completion inside the LMS and richer data than SCORM, without the launch guesswork of plain xAPI. The limitation is support. Several major authoring tools now export cmi5, but not all of them, and not every LMS plays it properly. Check both ends before you standardize on it.

Side by side

Where each one breaks in real projects

The spec comparison only gets you so far. These are the problems we see most often when auditing a course catalog or moving one between platforms.

SCORM

• Resume data truncated on long SCORM 1.2 courses. Republish as SCORM 2004 or split the course into shorter modules.
• A course that reports "completed" but never sends a score, so quiz results are invisible in the LMS. This is almost always a publish setting (tracking by slides viewed instead of by quiz result).
• A course that cannot find the API because it was opened in a way the package did not expect, for example a pop-up blocked by the browser.
• Multi-SCO packages that depend on sequencing rules the LMS does not implement.

xAPI

• The actor in the statements does not match the LMS user, so data lands in the LRS under an identity nobody can join to the learner record.
• Content that sends statements directly and drops them when the network blips.
• Custom verbs invented per course, which makes cross-course reporting painful later. Agree on a small verb list before the first build.

cmi5

• An AU set to CompletedAndPassed when it has no quiz, so the learner can never satisfy it.
• Content that never sends "terminated" when the learner closes the tab, leaving sessions open.
• An LMS that accepts the upload but only partly implements the launch rules.

A checklist for choosing

1. Will this course ever run outside your LMS? If it goes to a customer's LMS or a marketplace, SCORM is still the safest common format. Ask the other side which version they support.
2. Do you need completion and pass/fail as separate facts? Use SCORM 2004 or cmi5, not SCORM 1.2.
3. Is the course long, with lots of state to remember? Avoid SCORM 1.2.
4. Does the learning happen outside a launched course? That is xAPI territory, and you need an LRS you can query.
5. Who will read the data, and in which tool? If the answer is "the standard LMS reports", status and score may be all you need today.
6. Does your authoring tool export it and your LMS play it? Prove it with a real package, not a feature list.

Test before you roll out

Give every new authoring template an afternoon of testing. Publish the same short course in each format you are considering, upload each one, then check:

• Launch on a desktop browser and on a phone.
• Close the course halfway and reopen it. Does it resume on the right screen?
• Fail the quiz, then pass it. What status and score does the LMS record each time?
• Finish the content without taking the quiz, if the course allows it. Is the resulting status what you want?
• Open the learner record and the report your managers will actually use. Is the data where they will look?

When a result looks wrong and you cannot tell whether the package or the LMS is at fault, run the same zip in a neutral reference player such as Rustici's SCORM Cloud. If it misbehaves there too, the problem is in the publish settings.

You will probably run all three

Few organizations get to pick just one. There is a back catalog of SCORM 1.2 courses, newer builds in SCORM 2004 or cmi5, and some xAPI arriving from apps or simulations. Converting old SCORM courses is rarely worth the effort unless they are actually breaking. Put the energy into new builds instead.

That makes the LMS requirement simple to state: it must play every format you own and put the data somewhere useful. For reference, this is how LMS Advisor handles it, limits included. It plays SCORM 1.2 and SCORM 2004 packages, though multi-SCO packages launch their entry resource only, so full 2004 sequencing is not supported. It launches xAPI and cmi5 content and applies each AU's moveOn rule. The built-in LRS stores statements and state while packages run, which is what content needs to track progress and resume. It is not a reporting LRS you can query for analysis, so if you want to slice xAPI data you add an external LRS endpoint. Statements are queued and forwarded with retries, and each endpoint has a test button so you can confirm the connection before a course goes live.

The e-learning standards page has the details. If you would rather see your own packages run, book a demo and bring a zip file.