SCORM vs xAPI vs cmi5 vs LTI: Which Standard, When

Why this matters

If you are building or buying a learning product, a buyer's first question is almost always "which standards do you support?" — and the wrong answer either loses the deal or commits your engineers to months of avoidable work. This article is for the L&D director, EdTech founder, training lead, or product manager who has read about SCORM, xAPI, cmi5, and LTI separately and now needs to decide which to actually build. We give you the one decision that settles most cases, a comparison table you can hand to a vendor, a decision tree, and the video-specific guidance that the generic "SCORM vs xAPI" articles skip. Every standards claim is tied to the named specification and version, so an engineer can trust it and a non-technical reader can act on it.

The four standards in one sentence each

Before comparing them, refresh what each one is, in plain language. You do not need the deep version for this article — each links to its own explainer if you want it.

SCORM — short for Sharable Content Object Reference Model — is the standard that packages an e-learning course into a zip file so that any compliant learning management system (LMS) can load it, play it, and record a fixed set of results: did the learner complete it, what score did they get, how long did it take. Think of SCORM as a shipping container for a course: any compliant system can load it without knowing what is inside. The two versions you meet are SCORM 1.2 (1999) and SCORM 2004 (the 4th Edition is the last). It is run by ADL, the US Department of Defense's Advanced Distributed Learning Initiative.

xAPI — the Experience API, once nicknamed "Tin Can API" — is the standard for recording learning experiences as short sentences and storing them in a dedicated database. Each record is one statement: "Maria completed Module 3." The database those sentences go into is called a Learning Record Store (LRS). The key difference from SCORM is that xAPI can record learning that happens anywhere — a mobile app, a simulation, a VR headset, a real-world task signed off by a manager — not just inside an LMS. ADL published xAPI 1.0.3; the standard was later ratified as IEEE 9274.1.1-2023, the version sometimes called xAPI 2.0.

cmi5 — pronounced "C-M-I-five" — is a rulebook that sits on top of xAPI and adds the structure SCORM had and raw xAPI lacked: how to package a course, how to launch it from an LMS, and what "completed" and "passed" officially mean. If xAPI is a free-form notebook, cmi5 is the lined page with headings. ADL maintains it, and the same organization that created SCORM now points to cmi5 as SCORM's modern successor.

LTI — Learning Tools Interoperability — is different in kind from the other three. It does not package or track content; it launches your externally hosted tool inside an LMS through a secure, signed handshake. Your video platform stays on your servers; the LMS opens a trusted door into it. LTI is run by 1EdTech (formerly IMS Global); the current version is LTI 1.3 with the LTI Advantage services on top.

The one question that settles most cases

Here is the distinction that resolves most of the confusion: two of these standards move content into the LMS, one records data outside it, and one launches a tool that never moves at all.

SCORM and cmi5 are packaging standards. You build a course, zip it, and the LMS stores and runs that file. The content lives inside the LMS.

xAPI is a tracking standard. It does not package anything. It defines how a system reports what a learner did, and where that report is stored (the LRS). Content can live anywhere; xAPI just records the experience.

LTI is a launch (or integration) standard. Your content stays a live service on your own infrastructure, and the LMS launches into it on demand. Nothing is packaged and moved.

So the first question to ask is not "which is best" but "does my content need to be a file the LMS owns, or a live service I host?" If it must run inside a client's LMS — even offline, even after you are gone — you package it (SCORM or cmi5). If it is a living tool you update continuously and many institutions plug into, you launch it (LTI). xAPI then answers a separate question: how much do I need to know about what the learner did?

Figure 1. Two questions, four standards. The horizontal axis asks whether content is packaged into the LMS or launched as a live tool; the vertical axis asks whether you need only fixed completion data or rich, anywhere tracking. Each standard sits where it does its best work.

The second question: how much do you need to track?

Once you know whether you are packaging or launching, the second question is about data. The single most common mistake in this whole area is believing "SCORM tracks everything." It does not.

SCORM tracks a fixed data model inside an LMS launch: completion status, success status, a score, time spent, and a limited set of interactions (which question, right or wrong). That is plenty for compliance training — "did all 4,000 employees finish the security course?" — but it cannot tell you that a learner re-watched the third minute of a video four times, or that they practised a task in a separate app.

xAPI tracks anything you choose to describe as a statement, and it works outside the LMS. That includes rich video behaviour — played, paused, sought to a new position, completed — through a companion rulebook called the xAPI Video Profile. If your learning product's value is in understanding how people watch and interact, not just whether they finished, you need xAPI-level tracking.

cmi5 gives you xAPI's rich tracking and SCORM-style launch-and-completion structure in one package, which is why ADL positions it as the successor to SCORM for new content.

LTI does not track learning data itself at all in its core form. It carries identity and context (who the learner is, which course), and through its optional Assignment and Grade Services it can write a grade back to the LMS gradebook — but for detailed learning analytics you still pair LTI with xAPI behind the scenes.

The full comparison

The table below is the one most teams actually want: the four standards across the criteria that drive a build-vs-buy decision. Per our house rule, it includes an explicit standards-role column so nobody confuses a packaging standard with a launch standard.

Read the "What it is" row first. SCORM and cmi5 package; xAPI tracks; LTI launches. Almost every "which should I use" argument dissolves once that row is clear.

Figure 2. SCORM and cmi5 package content; xAPI records experiences to an LRS; LTI launches a live tool. The green cells mark each standard's strongest fit.

A decision tree you can actually follow

The table tells you what each standard does; the tree below tells you which to reach for. Walk it top to bottom and stop at the first answer that fits.

Start with the packaging question. Does your content need to be a self-contained file that runs inside a client's LMS, possibly offline? If yes, you are packaging — go to the next question. If no, and your content is a live tool you host and update, you are launching: use LTI 1.3, and pair it with xAPI behind the scenes if you need detailed analytics.

If you are packaging, ask: do you only need completion, score, and time, and must it work in old or strict LMSs? If yes, use SCORM (prefer 2004 4th Edition; fall back to 1.2 only if a target LMS demands it). If you need richer tracking — video behaviour, mobile, offline activities — use cmi5, which gives you that data while keeping SCORM-style launch and completion semantics.

If your learning happens mostly outside a traditional LMS — a mobile app, a simulation, on-the-job tasks, a custom platform you are building from scratch — skip packaging entirely and use pure xAPI with your own LRS.

The honest caveat: this tree gives you the primary standard. Real products often implement a second one for compatibility — for example, a cmi5 package for modern clients plus a SCORM 1.2 fallback for an old corporate LMS that has not upgraded.

Figure 3. A decision tree. The first split is package-or-launch; the second is how much you need to track; the third is whether learning happens inside or outside the LMS.

The video angle the generic comparisons miss

Most "SCORM vs xAPI" articles never mention video specifically, which is exactly where a learning-video product lives or dies. Here is the part that matters for you.

A raw video player on its own tracks nothing an LMS understands. SCORM can record that a module containing a video was completed, but it cannot tell you how the video was watched — and "watched 100%" is not the same as "completed" and certainly not "learned." If your product's value is in understanding watch-time, drop-off, re-watches, and where attention falls, SCORM's fixed model is a dead end.

xAPI, through the xAPI Video Profile, is built for exactly this: it defines statements for played, paused, seeked, completed, plus the data to reconstruct a watch-time heatmap. cmi5 carries those same xAPI statements while also giving the LMS a clean "completed/passed" signal. So for a learning-video product, the pattern is almost always: package with cmi5 (or track with pure xAPI) for the video data, and launch with LTI when your player is a hosted tool that institutions embed. The detailed how-to lives in tracking video with xAPI.

A worked example: one product, the real integration cost

Numbers make the choice concrete. Suppose you sell an interactive-video course product to two kinds of buyer: a modern corporate client running a current LMS, and a university running an old institutional LMS that only speaks SCORM 1.2. You want rich video analytics from both.

If you bet everything on a single standard, one buyer loses. Pure xAPI gives you the analytics but will not satisfy the university's "must be a SCORM package in our LMS" requirement. SCORM 1.2 satisfies the university but throws away the video data the corporate client is paying for.

The pragmatic build supports two standards from one content source:

Content built once (the interactive video course)
  ├─ Export A: cmi5 package      → rich xAPI video data + clean completion   (modern clients)
  └─ Export B: SCORM 1.2 package → completion + score only                    (legacy LMSs)
Add LTI 1.3 launch               → for clients who want the live hosted player

The cost is not "build it four times." It is "build the content once, then add export targets." A second packaging export is typically days, not weeks, when the authoring layer is designed for it from the start — which is the whole argument for deciding your standards before you build, not after.

Common mistakes that cost real time

A handful of misunderstandings recur on almost every learning-product project, and each is cheap to avoid up front.

The first is treating the four as competitors that you must choose between. They are not mutually exclusive. SCORM/cmi5 package, xAPI tracks, LTI launches — a single product routinely uses two or three.

The second is believing SCORM tracks everything. SCORM tracks a fixed data model. Rich interactions and video behaviour need xAPI or cmi5. Promising a client "detailed video analytics" on a SCORM 1.2 build is a promise you cannot keep.

The third is confusing "xAPI" with "Tin Can API" as if they were different things. Tin Can was the project's working name; xAPI (Experience API) is the standard. Cite the version — 1.0.3, or IEEE 9274.1.1-2023 for the ratified 2.0.

The fourth is describing LTI as a login. LTI 1.3 proves identity with a signed token (a JWT) that your tool verifies cryptographically; single sign-on is the result, not the mechanism. Model it as a password handoff and you build the wrong, less secure thing.

The fifth is picking the standard after building the content. The standards decision shapes how you author and store content. Decide first; retrofitting a tracking model onto finished content is the expensive path. Use the standards decision worksheet to settle it before a line of content is built.

Where Fora Soft fits in

Fora Soft has built video learning, streaming, conferencing, and interactive-player software since 2005, across 239+ shipped projects. On learning products, the standards decision in this article is one of the first we help teams make, because getting it wrong is expensive to undo. The build-vs-buy framing we use is simple: package with SCORM or cmi5 when content must live inside a client's LMS, track with xAPI when the value is in detailed video and interaction analytics, and launch with LTI when your player is a live service many institutions embed. Our work usually sits at the video and interactive layer — an interactive-video product that exports a cmi5 package for rich watch-time data, ships a SCORM fallback for older LMSs, and offers an LTI 1.3 launch with grade passback for clients who want the hosted experience. We treat that multi-standard support as a design decision made before authoring, not a patch added after.

What to read next

• Tracking video with xAPI: the video profile and what to capture
• cmi5: the bridge between SCORM and xAPI
• Packaging and delivering content: manifests, hosting, and the cloud

Call to action

• Talk to a e-learning engineer — book a 30-minute scoping call to talk through your scorm vs xapi plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Learning-Standards Decision Worksheet — A one-page worksheet that walks you through the package-vs-launch and tracking-depth questions to pick SCORM, xAPI, cmi5, or LTI for your learning-video product, with a quick capability matrix and a privacy gate.

References

1. Advanced Distributed Learning (ADL). SCORM 2004 4th Edition — Run-Time Environment (RTE) and Content Aggregation Model (CAM). https://adlnet.gov/projects/scorm/ (Tier 1 — primary specification; SCORM's packaging model and the fixed run-time data set: completion status, success status, score, total time, and the interactions model.)
2. Advanced Distributed Learning (ADL). SCORM 1.2. https://adlnet.gov/projects/scorm/ (Tier 1 — primary specification; the earlier, most widely deployed SCORM version and its compatibility role.)
3. Advanced Distributed Learning (ADL). Experience API (xAPI) Specification, Version 1.0.3. https://github.com/adlnet/xAPI-Spec (Tier 1 — primary specification; the statement model (actor-verb-object), the Learning Record Store, and tracking of learning outside the LMS.)
4. IEEE Standards Association. IEEE 9274.1.1-2023 — Experience API (xAPI) Base Standard. https://standards.ieee.org/ieee/9274.1.1/7321/ (Tier 1 — primary standard; the IEEE-ratified xAPI base standard, approved 30 March 2023, published 6 October 2023, the version informally called xAPI 2.0.)
5. Advanced Distributed Learning (ADL). cmi5 Specification (Quartz). https://github.com/AICC/CMI-5_Spec_Current (Tier 1 — primary specification; cmi5 as an xAPI profile that adds launch, authorization, session, and completion/pass semantics to xAPI.)
6. ADL Initiative. xAPI Profiles — Video Profile. https://adlnet.gov/projects/xapi-profiles/ (Tier 1 — primary profile; the xAPI statements for video — played, paused, seeked, completed — used for video analytics.)
7. IMS Global Learning Consortium (1EdTech). Learning Tools Interoperability (LTI) Core Specification, Version 1.3, IMS Final Release, 16 April 2019. https://www.imsglobal.org/spec/lti/v1p3 (Tier 1 — primary specification; the Platform/Tool roles, the OIDC launch, and the signed JWT that carries identity and context.)
8. IMS Global Learning Consortium (1EdTech). LTI Advantage Overview (Deep Linking, Names and Role Provisioning Services, Assignment and Grade Services). https://www.imsglobal.org/lti-advantage-overview (Tier 1 — issuing-body documentation; the optional services, including grade passback via AGS.)
9. Rustici Software. Comparison of SCORM, xAPI and cmi5. https://xapi.com/cmi5/comparison-of-scorm-xapi-and-cmi5/ (Tier 4 — vendor engineering reference; used only for "what actually ships" and current adoption framing, never to override the spec.)
10. ADL Initiative. cmi5 — the successor to SCORM (positioning). https://adlnet.gov/projects/cmi5-specification/ (Tier 1 — issuing-body documentation; ADL's positioning of cmi5 as the modern path for new content.)

Where lower-tier vendor sources (Rustici/xAPI.com) framed adoption or "which to choose" guidance, the article follows the primary specifications for every standards claim — notably that SCORM tracks a fixed data model (ADL SCORM 2004 RTE), that xAPI/cmi5 are required for rich video tracking (the xAPI Video Profile), and that LTI's SSO is a consequence of the signed-JWT launch, not a password login (IMS LTI 1.3).