Choose the newest standard your LMS reliably supports—not the newest acronym on the list. For many conventional courses, all three can record completion and results. The practical difference is compatibility, reporting behaviour, and what you want to track.
The short answer
SCORM 1.2
A familiar choice for standard LMS courses when compatibility matters more than sophisticated data.
SCORM 2004
Separates completion and success more cleanly and adds sequencing capabilities, if the LMS supports it well.
xAPI
Records flexible activity statements through a Learning Record Store and can track experiences beyond a conventional course.
Articulate recommends confirming which standard and reporting option the LMS provider requires. A technically capable package is still the wrong package if the receiving platform does not support it correctly.
SCORM and xAPI compared side by side
| Decision factor | SCORM 1.2 | SCORM 2004 | xAPI |
|---|---|---|---|
| Typical use | Standard LMS course tracking | More robust LMS status and sequencing | Flexible learning activity data |
| Completion and success | One status value can create interpretation differences | Separate status values improve clarity | Can report completion and success through supported tools |
| Sequencing | Limited | Formal sequencing and navigation rules | Not the same course-sequencing model |
| Data destination | LMS | LMS | Learning Record Store, sometimes connected to an LMS |
| Beyond-course tracking | Limited | Limited | Designed for broader activity and experience statements |
| Best reason to choose it | Your LMS requires it or it is the proven compatible option | You need more reliable status handling or sequencing | You have an LRS and a real reporting plan for richer data |
When SCORM 1.2 makes sense
SCORM 1.2 is an older standard, but age does not automatically make it unusable. It remains common in established LMS environments and is often enough for a course that needs to launch, bookmark progress, record a score, and report a completion result.
The main limitation is that SCORM 1.2 reports a single status value. Different LMSs can interpret that value differently when producing separate completion and success results. It also has a smaller suspend-data allowance than newer options, which can matter in long or complex Storyline courses.
Choose SCORM 1.2 when:
- The LMS explicitly requires it.
- The organization has a proven SCORM 1.2 publishing and testing process.
- The course needs conventional completion, score, and resume behaviour.
- Broad compatibility is more important than advanced sequencing or richer activity data.
When SCORM 2004 makes sense
SCORM 2004 separates completion status from success status, making it easier for an LMS to understand that a learner can complete a course and still fail an assessment—or pass an assessment before every required activity is complete.
It also introduced formal sequencing and navigation rules. Those rules can control how learning objects are presented, but they add implementation and testing complexity. Do not choose SCORM 2004 for sequencing unless the course and LMS genuinely need it.
Choose SCORM 2004 when:
- The LMS supports the selected edition reliably.
- Completion and pass/fail need to be reported as distinct results.
- The course needs sequencing capabilities that have been designed and tested intentionally.
- A larger suspend-data allowance is useful for a more complex course.
When xAPI makes sense
xAPI represents activity as structured statements built around an actor, verb, and object. Those statements are stored in a Learning Record Store. That model can capture more varied learning experiences than a conventional LMS launch and completion record.
The extra flexibility is valuable only when the organization has an LRS, a defined data model, and someone prepared to use the information. Publishing an xAPI package without a reporting plan is not a data strategy; it is just a fancier zip file.
Choose xAPI when:
- Your LMS or learning ecosystem supports xAPI and an LRS is available.
- You need meaningful activity detail beyond completion and score.
- You want to connect learning records across simulations, practice, coaching, mobile activity, or other experiences.
- The organization has agreed on the statements, identifiers, governance, and reporting that will make the data useful.
A practical decision path
Ask the LMS owner which standards and editions are supported, recommended, and already used successfully.
Define the required reporting: launch, resume, completion, score, pass/fail, interaction data, or broader activity statements.
Choose the simplest supported standard that meets the reporting requirement.
Test the exact published package in the actual LMS before launch. A successful upload is not the same as a successful course.
What to test before launch
- The course launches correctly from the LMS, including pop-up and browser behaviour.
- Progress resumes from the expected location after closing and returning.
- Completion and success statuses appear correctly for passing, failing, and incomplete attempts.
- Scores, attempts, and interaction data match the agreed reporting requirement.
- Mobile, keyboard, and accessibility behaviour still works inside the LMS player.
- The final production package—not an earlier test build—is the version assigned to learners.
If the same package behaves differently across platforms, isolate whether the issue belongs to the course output, the LMS interpretation, or the launch environment before rebuilding the course.