SCORM players, runtimes and debuggers
Run a SCORM package outside an LMS — and watch what it actually does.
Compiled and checked by the scorm-tools.com editor. Last updated .
A SCORM package is inert until something gives it an API to talk to. That something is a runtime: the
JavaScript object a course looks for on window.API (SCORM 1.2) or window.API_1484_11 (SCORM 2004),
which answers LMSInitialize, GetValue, SetValue and Commit and persists the data model somewhere.
The tools here fall into three groups that are easy to confuse. Runtimes and API wrappers are libraries you embed — either in a course, to talk to whatever LMS it lands in, or in your own application, to play the role of the LMS. Players are complete applications that unzip a package, serve it, and drive it end to end. Debuggers are players with the lid off: they show the API call transcript, the current CMI data model, suspend data, sequencing decisions and the moment something returns error 101.
If you are testing whether a package works before it reaches a client's LMS, start with a debugger. If you are building a product that must host SCORM content, start with a runtime and read its persistence adapter carefully — that is where most integrations go wrong.
5 tools · 4 open source · 0 support cmi5
Order is editorial and never for sale: standards coverage first, then maintenance state, then popularity, then alphabetical. How we list .
Tools in this category
Filter these tools
Showing 5 of 5
Standards supported: 1.2 · 2004 · AICC
Licence: GPL-3.0-or-laterPricing: Open sourceStandards supported: 1.2 · 2004
Licence: ProprietaryPricing: FreeStandards supported: 1.2 · 2004
Licence: MITPricing: Open sourceQuestions people ask about players, runtimes & debuggers
What is the difference between a SCORM player and a SCORM runtime?
A runtime is a library that implements the SCORM API surface a course calls; a player is a whole application that loads a package, hosts it in an iframe and provides that runtime. Every player contains a runtime, but you can embed a runtime without a player.
Do I need a full LMS just to check a package works?
No. An in-browser debugger will unzip the package locally, serve it, and show you every API call it makes. That catches the majority of packaging faults — missing manifest entries, wrong SCORM version, completion never being set — in a minute rather than a deployment cycle.
Why does my course work in one player but not in an LMS?
Usually one of three things: the LMS enforces the data-model constraints the player relaxes (string lengths, vocabularies, read-only elements), the LMS restricts cross-origin access to the API object, or the course relies on a sequencing behaviour the LMS implements differently. Tools with LMS quirk profiles exist specifically to reproduce these differences.
Which JavaScript runtime should I embed in a new project?
Look for one that supports both SCORM 1.2 and 2004, is still receiving commits, and has an explicit persistence interface so you can decide where learner state goes. The listings here show the standards matrix and the last commit date for exactly that comparison.