SCORM vs. xAPI: The difference for companies

SCORM and xAPI in brief

Both are technical standards for digital learning, but with different aims. SCORM (Sharable Content Object Reference Model) describes how a course starts in a learning management system (LMS) and reports back progress and results. xAPI (Experience API, formerly "Tin Can API") goes further: it records individual learning experiences as data records – regardless of whether they take place in the LMS, in an app, in a simulation, or offline. Both originate from the environment of the US initiative Advanced Distributed Learning (ADL). In short: SCORM standardizes the course, xAPI the individual learning experience.

The difference at a glance

The following table compares the most important criteria – from the basic idea to data storage to standardization status. The sections below explore each dimension in more depth.

Origin and purpose: why both standards exist

SCORM and xAPI solve the same basic task – learning content and learning systems should work together independently of the vendor – at different times and with different reach. Both go back to the US initiative Advanced Distributed Learning (ADL), which was originally intended, on behalf of the US Department of Defense, to enable interoperable, reusable e-learning content.

SCORM emerged around the turn of the millennium. The most widely used version to this day, SCORM 1.2, dates from 2001; SCORM 2004 followed in several editions up to 2009 (overview of SCORM versions). The ADL Initiative formulated clear design goals: interoperability, portability, and reusability of learning content across different systems. A course, once created, should run on any compatible platform without being rebuilt for each system. SCORM is optimized around this purpose – and this is also where it reaches its limits as soon as learning leaves the classic course.

xAPI was developed as a response to precisely these limits and finalized as version 1.0 in 2013. The former name "Tin Can API" comes from the development project through which ADL had a practical successor to SCORM developed; the guiding idea was an interface that also records learning where no LMS runs in the browser. Mobile learning, apps, simulations, and informal learning activities in the workplace could not be mapped cleanly with SCORM. xAPI therefore shifts the focus from the course to the individual learning experience: what is recorded is who did what – no matter where. Both standards exist side by side today because they answer different questions.

How SCORM works technically

SCORM is not a single format but a bundle of three interrelated specifications. The ADL Initiative describes SCORM as a collection of "books" that together govern the packaging, execution, and control of a course. Three building blocks are decisive for the comparison with xAPI: Content Packaging, Run-Time, and Sequencing.

Content Packaging (Content Aggregation Model)

The Content Aggregation Model specifies how a course is packaged and described. The content is bundled into a self-contained ZIP package, at whose root lies an XML file named imsmanifest.xml. This manifest describes all components and their structure and contains all the information the LMS needs to deliver the course; such a package is also referred to as a Package Interchange File (PIF). Because the package is standardized, the same course can be imported into any SCORM-capable LMS – the basis of reusability. In practice, almost all common authoring tools export to SCORM, which explains its wide distribution and makes it easier to exchange courses between providers.

Run-Time Environment

The Run-Time specification governs how a course is launched and communicates with the LMS. The LMS opens the content in a web browser and provides a JavaScript interface (API) through which the course exchanges data – such as score, status, or elapsed time. The LMS only ever launches a single Sharable Content Object (SCO) at a time. A key limitation follows from this architecture: because communication runs via the browser and a shared data model, the content must reside in the same web domain as the LMS and requires a browser.

Sequencing & Navigation

Sequencing & Navigation controls the order in which learning units may be completed. To put things in context, a point that is often confused: this "book" was only added with SCORM 2004 (first edition 2004) – SCORM 1.2 did not yet include it. The sequencing rules of the first edition were considered difficult to implement; later editions specified them more precisely, and the 4th Edition of 2009 refined them further and added individual navigation options. So the 4th Edition did not introduce sequencing but merely matured it.

How xAPI and the Learning Record Store work

xAPI removes the tie to the browser and the LMS domain by logging individual events rather than courses. Instead of reporting "course passed", xAPI writes small, self-contained data records – the xAPI statements. Because the format is open and extensible, specialist applications beyond classic courses can also contribute learning data. They are stored in a separate system, the Learning Record Store.

The xAPI statement (Actor – Verb – Object)

An xAPI statement follows the form "someone – did – something", technically Actor – Verb – Object. An Actor is the learner, the Verb the action (such as "completed", "passed", or "experienced"), the Object the activity to which the action refers. Additional fields such as result or context add details. A concrete example: "Anna" (Actor) completed the fire safety module (Verb and Object), supplemented by a result (passed, 92 percent) and a context (as part of the annual instruction). Because this model is freely extensible, activities that take place outside a classic course can also be recorded: completing a simulation, watching a video, a task in a mobile app, or an action in the workplace.

The role of the LRS

The Learning Record Store (LRS) is the heart of xAPI: a system that receives, stores, and makes learning records retrievable again via a standardized interface. An LRS can be part of an LMS or be operated independently. Because the statements are sent via a web interface and do not require a permanently open browser, they can first be recorded offline and transmitted later – the technical basis for mobile and distributed learning. And because data from several sources converges in an LRS, a cross-cutting database for learning analytics is created there.

cmi5 – the bridge between both worlds

Between SCORM and xAPI stands cmi5: an xAPI profile that defines rules for content launched from the LMS – i.e., for launch, authorization, session management, and reporting. cmi5 connects the orderly LMS world of SCORM with the flexibility of xAPI and is often described as the functional successor to SCORM: content is launched from the LMS as usual but uses xAPI and an LRS in the background. cmi5 was developed by ADL and the aviation initiative AICC; after the latter's dissolution, the profile passed to ADL, and it was first published in 2016. In practice, cmi5 is thus the common way to switch gradually from SCORM to xAPI without giving up the existing course base.

The most important comparison dimensions in detail

Behind the overview table lie a few differences that are decisive for the selection. Three dimensions are particularly relevant: the data model, the reach across devices and locations, and the analyzability of the collected data.

Tracking scope and data model

The core of the difference lies in the data model. SCORM works with a fixed set of values specified by the LMS – essentially completion, score, status, and time via the Run-Time interface. This is sufficient to document the completion of a course but does not map individual actions. xAPI reverses the principle: every action is a separate, freely formulated data record. This makes it possible to capture not only "course passed" but also finely granular activities – right down to informal learning that does not occur in a SCORM course at all.

Offline, mobile, and interoperable

SCORM requires a browser and the same web domain as the LMS, which makes mobile and offline learning more difficult. xAPI is not tied to any browser: statements can come from apps, simulations, or devices, be buffered offline at first, and be sent to the LRS later. This way, a mobile app can record safety instruction on a tablet directly in the factory hall and synchronize the data later. In terms of interoperability, the two standards work differently – SCORM makes the course portable (one package, any compatible LMS), xAPI makes the learning data portable (collected in the LRS, independent of the individual learning tool).

Reporting, learning analytics, and data protection

Because an LRS brings together learning data from different sources in one place, xAPI enables much deeper learning analytics than the basic reporting of SCORM. In practice, this allows analyses that go beyond mere completion – for example, at which point learners frequently drop out, how formal courses and informal activities complement each other, or which content is actually used in which order. SCORM provides the completion data, xAPI additionally the path to it. This is also a data protection issue: the more detailed the recording of learning behavior, the more important purpose limitation, data minimization, and – where possible – anonymization or pseudonymization become. Anyone who analyzes beyond the mere proof of completion should deliberately define and document the scope of recording.

Common misconceptions about SCORM and xAPI

A number of misconceptions persist around the comparison that make selection more difficult. Four of them are particularly widespread:

• xAPI does not automatically replace SCORM. xAPI extends the possibilities but does not supersede SCORM; for classic courses, SCORM remains the widespread standard, and both are often operated in parallel.
• An LRS is not an LMS. The Learning Record Store stores and delivers learning records but manages neither courses nor users or access – that remains the task of the LMS. Both can be the same system, but they do not have to be.
• cmi5 is not the same as xAPI. cmi5 is a set of rules based on xAPI that closes the gap between LMS launch and free recording; without cmi5, xAPI does not specify how content is launched from the LMS.
• SCORM is not outdated. Although SCORM no longer receives new versions, it is still widely supported and fully functional for self-contained courses; a lack of ISO status does not mean a lack of practical suitability.

Standardization status: xAPI is now an IEEE standard

An important point for future-proofing: xAPI was finalized as version 1.0 in 2013 and has since been formally standardized as IEEE 9274.1.1-2023 – and additionally adopted internationally in 2025 as ISO/IEC/IEEE 39274-1-1:2025. Maintenance thus lies with established standards bodies. SCORM, by contrast, remains an ADL specification without ISO status – but as a de facto industry standard, it is still very widely used. The original code projects of the ADL Initiative are archived, while the specifications remain valid in substance – so xAPI is not a model being phased out but has transitioned into formal standardization.

What the difference means when switching LMS

A practical advantage of both standards is vendor independence, but it works differently. Because a SCORM package can be imported into any SCORM-capable LMS, courses can as a rule be taken along when switching platforms without having to recreate them. With xAPI, the value lies less in the course than in the learning data: since it is collected in a Learning Record Store, the learning history is preserved even if the learning tool changes – provided the LRS is taken over or the data is migrated. Anyone who values long-term analyzability should therefore consider the LRS as a separate building block and not tie it solely to a specific LMS. For the switch itself, cmi5 is often the pragmatic path: existing courses continue to run, new content is already recorded on an xAPI basis, and the learning data accumulates in the LRS from the outset.

Using SCORM and xAPI together

SCORM and xAPI are not mutually exclusive – rather, many organizations deliberately use both side by side. SCORM remains where it works reliably: for self-contained mandatory and specialist courses whose completion must be documented. xAPI covers the scenarios that SCORM cannot map – mobile learning, simulations, or the analysis of informal learning activities. The technical bridge is often cmi5: content launches from the LMS as usual but uses xAPI and an LRS in the background. This allows a gradual switchover without giving up the existing course base. The choice is therefore rarely an either-or, but a question of which learning scenario needs which standard.

Which standard for which case?

As a decision aid: SCORM is the right choice for structured courses in the LMS where course completion counts – the most common case for mandatory and compliance training. For recurring mandatory data protection or occupational safety training whose completion must be traceably documented and proven, SCORM is as a rule the simpler and sufficient choice; only when learning paths are to be analyzed across multiple channels does xAPI play to its strengths. xAPI is worthwhile when learning goes beyond the course boundary: mobile learning, apps, simulations, informal learning in the workplace, or when learning data from several sources is to be brought together and analyzed. cmi5 is the middle ground when content should continue to launch from the LMS in an orderly manner but the flexibility of xAPI is to be used in the background.

If the choice falls on xAPI, the LRS moves into focus. Sensible selection criteria include: conformity with the current specification (IEEE 9274.1.1-2023), support for cmi5, import and export options for the learning data (so that the history remains migratable), reporting and analysis functions, and data protection options such as access control and anonymization. Whether a standalone LRS is necessary or the one integrated into the LMS is sufficient depends on how many learning sources converge and how deeply the data is to be analyzed.

What matters, then, is not which standard is "better" but which learning scenario is to be mapped; it is important to align the choice with the specific use case and not with the question of which standard is technically newer. A modern learning platform can take part of this technical decision off companies' hands if it already comes with the required standards.

A note on our own behalf: The Bridgly learning platform supports common e-learning standards and comes with suitable reporting, so the focus can be more on the training content than on the question of standards.

You can find more articles on e-learning and digital professional development in the topic hub HR & Learning.

Is xAPI the successor to SCORM?

Not in the sense of a replacement. xAPI extends the capabilities of SCORM with tracking outside the LMS, but SCORM remains widespread for classic courses. cmi5, an xAPI profile for content launched from the LMS, is considered the functional bridge. In practice, both standards are often used in parallel.

What is a Learning Record Store (LRS)?

An LRS is a system that stores learning records captured with xAPI via a standardized interface and makes them retrievable again. It can be operated independently or be part of an LMS and brings together learning data from different sources.

Do we need a new LMS for xAPI?

Not necessarily. Many learning platforms support both SCORM and xAPI and come with an LRS. Whether an additional, standalone LRS makes sense depends on how many learning sources are to be brought together and how deeply the data is to be analyzed.

• ADL Initiative – SCORM (Content Aggregation Model, Run-Time, Sequencing & Navigation): adlnet.gov/research/scorm (as of 30 May 2026)
• Rustici Software – SCORM Versions (version history): scorm.com/scorm-versions (as of 30 May 2026)
• Rustici Software – SCORM Content Packaging (imsmanifest.xml): scorm.com/content-packaging (as of 30 May 2026)
• Rustici Software – SCORM Run-Time Environment: scorm.com/run-time (as of 30 May 2026)
• Rustici Software – SCORM Sequencing & Navigation: scorm.com/sequencing (as of 30 May 2026)
• Rustici Software – SCORM 2004 4th Edition (2009): scorm.com/scorm-2004-4th-edition (as of 30 May 2026)
• xAPI – History (version 1.0, April 2013): xapi.com/history (as of 30 May 2026)
• xAPI – Anatomy of a Statement (Actor–Verb–Object): xapi.com/statements (as of 30 May 2026)
• xAPI – Tech Overview (Learning Record Store): xapi.com/tech-overview (as of 30 May 2026)
• xAPI – cmi5: xapi.com/cmi5 (as of 30 May 2026)
• IEEE 9274.1.1-2023 (xAPI standard): standards.ieee.org (as of 30 May 2026)
• ISO/IEC/IEEE 39274-1-1:2025: standards.ieee.org (as of 30 May 2026)
• Featured image: AI-generated; labeled "Created with AI" as an overlay in line with Art. 50 EU AI Act. License/creation record will be added during image production (provider/date).