SCORM 1.2 vs. SCORM 2004: which version your LMS actually expects

When you publish an eLearning module, your authoring tool asks which version of SCORM you want. The reasonable answers are SCORM 1.2, SCORM 2004 (3rd Edition), and SCORM 2004 4th Edition. The unreasonable answer — picking whichever option is selected by default — is what most teams do, which is fine right up until the LMS rejects the upload.

This is a short reference for L&D teams who don't want to read the official spec but do want to make the right choice the first time.

What changed between 1.2 and 2004

SCORM 1.2 launched in 2001 and is, charitably, a snapshot of the early 2000s web. It defines a small API your module uses to report status to the LMS: cmi.core.lesson_status, cmi.core.score.raw, completion times, and a handful of other fields. It works. It's been working for twenty-five years.

SCORM 2004 (across its four editions) added two big things: sequencing and navigation (rules about which lessons unlock when), and granular interaction tracking (every quiz answer, time spent per lesson, retry attempts). It also reorganised the API — cmi.core.score.raw became cmi.score.raw, lesson_status split into completion_status and success_status, and so on.

The practical differences for L&D teams

Tracking

• SCORM 1.2:reports completed/passed/failed and a single score. Sufficient for compliance training, mandatory annual modules, “did the employee finish this?”
• SCORM 2004: reports each interaction individually. The LMS knows which question they got wrong, how long they spent on chapter 3, how many retries on the assessment.

Branching and sequencing

• SCORM 1.2: the module decides its own flow. The LMS just launches it.
• SCORM 2004:the LMS can enforce sequencing rules — “don't allow the learner to take chapter 3 until they pass chapter 2's quiz.” Useful for curriculum design; rarely used in practice because it's a configuration nightmare.

Mobile and modern web

Both versions emit JavaScript that runs in a browser. Neither was designed for the mobile-first web. In 2026, the version doesn't matter much for mobile compatibility — the authoring tool's responsive design does. (For what it's worth, anything generated by MLtitude is responsive by default, on either version.)

LMS support

• SCORM 1.2: universally supported. Every LMS that has ever existed can host SCORM 1.2 content.
• SCORM 2004 3rd Edition: supported by all current major LMSes.
• SCORM 2004 4th Edition: supported by most current major LMSes, but a handful of older or niche systems still expect 3rd Edition. Confirm with your LMS admin before publishing.

How to choose, in 30 seconds

Ask three questions:

• Does the LMS need to know which questions the learner got wrong? If yes → SCORM 2004. If no → SCORM 1.2.
• Does the LMS enforce sequencing rules between modules? If yes → SCORM 2004. If no → SCORM 1.2.
• Does your LMS admin have a preference? They usually do. Ask. They can save you a debugging session.

What about xAPI / Tin Can?

xAPI is the next-generation standard. It is much more flexible than SCORM — you can track learning outside the LMS, capture any kind of activity, and store statements in a separate Learning Record Store (LRS). It is also less broadly supported than SCORM for module-style content.

For now, the pragmatic answer is: publish SCORM (1.2 or 2004) for LMS compatibility, and emit xAPI statements alongside if your LRS expects them. Most modern authoring tools — MLtitude included — support both at once.

The boring conclusion

Pick SCORM 1.2 unless you have a concrete reason to pick something else. The reasons are real but rare: detailed interaction tracking, cross-module sequencing, an LMS admin who specifically requested 2004. If none of those apply, 1.2 will work and your Friday will be calmer.

For a wider take on bringing existing training content into a SCORM-compliant format, see PowerPoint to SCORM: how to convert your training deck into an LMS-ready module.

Keep reading