Every time a learner clicks "launch" on an e-learning module and their completion shows up in an LMS gradebook, an interoperability standard is doing the work behind the scenes. These standards are the agreed-upon languages that let content talk to platforms. If you are selecting an LMS, buying off-the-shelf courses, or building custom content, understanding the differences between SCORM, xAPI, and cmi5 is not optional — it is foundational.
Let's start with SCORM, the Sharable Content Object Reference Model. SCORM has been the dominant standard in e-learning for over two decades. It defines how a piece of content is packaged (as a ZIP file with a manifest), how it communicates with a learning management system through a browser-based JavaScript API, and what data it can send back — things like completion status, score, time spent, and bookmark location. SCORM 1.2 and SCORM 2004 are the two versions you will encounter in the wild, and SCORM 1.2 remains remarkably widespread because it is simple and almost universally supported.
SCORM works well for traditional e-learning: a self-paced module that runs inside a browser window launched by an LMS. But it carries real limitations. Content must be launched from and run inside the LMS. It cannot track experiences that happen outside a browser — like mobile apps, simulations, virtual reality, on-the-job activities, or even a conversation with a coach. The data model is rigid; you get completion, pass/fail, a score, and a handful of interaction-level details, but you cannot easily capture richer learning behaviors. And SCORM assumes a single learner, a single session, and a single LMS.
xAPI, also known as the Experience API or sometimes Tin Can API, was designed to break through those walls. Instead of a browser-based handshake between content and LMS, xAPI uses a simple data format — the "statement" — structured as Actor-Verb-Object. "Jane completed Module 5." "Marcus answered question 12 correctly." "Priya watched the safety video on her phone." These statements are sent over HTTP to a Learning Record Store, or LRS, which is a database purpose-built to receive and store them.
The power of xAPI is its flexibility. Statements can be sent from virtually any system or device: a mobile app, a simulation engine, a chatbot, a point-of-sale system during on-the-job training, or even a manual entry by a manager who observed a skill demonstration. The vocabulary is extensible — you can define your own verbs and activity types — which means you can track nearly any learning-related experience. The LRS can live inside an LMS, or it can be a standalone system that aggregates data from many sources.
That flexibility, however, comes with a cost. Because xAPI does not prescribe how to handle course launching, sequencing, or completion rules, two organizations implementing xAPI may do so in incompatible ways. You gain expressiveness but lose some of the plug-and-play simplicity that made SCORM so widely adopted.
cmi5 was created to address exactly this tension. Think of cmi5 as a defined set of rules built on top of xAPI. It specifies how an LMS launches content, how the content authenticates with the LRS, what statements must be sent for key events like completion and pass/fail, and how sessions are managed. In other words, cmi5 gives you the rich data model and flexibility of xAPI with the interoperability guarantees that SCORM provided. If SCORM is a rigid contract and xAPI is a flexible language, cmi5 is a well-structured template written in that language.
So how should you think about choosing? If your ecosystem is entirely browser-based, self-paced e-learning and you need maximum vendor compatibility today, SCORM remains a safe and practical choice. If you are tracking diverse learning experiences across multiple platforms and devices and you have the technical capacity to design a coherent data architecture, xAPI gives you the most power. If you want the best of both worlds — structured course delivery with modern, extensible tracking — cmi5 is the standard to push toward, though you should verify that your LMS and authoring tools actually support it, because adoption is still growing.
Regardless of the standard you choose, a few practical principles apply. First, define what "completion" means before you build anything. Standards provide the mechanism for reporting completion, but the business logic — did the learner need to score 80 percent, or just view every page? — is your decision. Second, plan your data architecture. An LRS full of millions of xAPI statements is only valuable if you have defined what questions you want those statements to answer. Third, test interoperability early. Export a course package, import it into your LMS, launch it, complete it, and verify the data that lands in your reports. Assumptions about compatibility are the source of most integration headaches.
Understanding these standards turns you from a buyer who accepts whatever a vendor delivers into a leader who can ask precise questions, make informed trade-offs, and build a learning technology ecosystem that actually works together.