The short answer
A SCORM player is the software that does the LMS side of the SCORM runtime. It unzips the package, reads imsmanifest.xml, launches the content in a frame or window, places the API object where the content can find it, answers the course's GetValue and SetValue calls, and saves the result. Every LMS that imports SCORM contains one.
The name misleads because it sounds like a media player. A SCORM package is not a file you watch; it is a web page that expects a conversation with something on the other side, and the player is that other side. Open the page without one and it runs but records nothing, and most courses say so with an "API not found" message.
What does a SCORM player actually do?
The specification splits the work between content and LMS, and the player is the LMS's share. In order, its jobs are:
- Import. Unzip the package and parse
imsmanifest.xml: which version the package claims, the tree of items the learner will see, and which HTML file each launchable item — each SCO — starts from. A player that cannot parse the manifest rejects the package here. - Launch. When a learner opens a SCO, create a frame or pop-up window, load the SCO's launch file into it, and make sure the API object is reachable from there.
- Serve the API. Expose a JavaScript object named
API(SCORM 1.2) orAPI_1484_11(SCORM 2004) with the eight runtime functions: Initialize, Terminate, GetValue, SetValue, Commit, GetLastError, GetErrorString and GetDiagnostic (prefixedLMSin 1.2, soLMSInitializeand so on). - Keep the data model. Hold the current value of every element the version defines — status, score, location, suspend data, session time, interactions, objectives — and enforce their rules: which are read-only, which accept only a fixed vocabulary, how long a string may be. A
SetValuethat breaks a rule is refused with an error code, not stored. - Persist. Write the data model to the database on
Commitand again onTerminate. Some players also save on a timer or when the window closes; the specification requires only the two calls, so a course that never commits is relying on behaviour the player need not provide. - Sequence (SCORM 2004 only). Apply the manifest's rules for which item comes next, what must be passed before something unlocks, and how results roll up to the course. In 1.2 there are no such rules; the content decides.
Everything a learner sees is the content's work. Everything an administrator sees afterwards — status, score, time — passed through the player. The SCORM API explained covers step three function by function.
Player vs viewer
A viewer opens the HTML and lets it run. A player opens the HTML and provides the API object. That one difference decides whether anything is recorded, and it is why unzipping a package and double-clicking index.html is a poor test of whether a course works.
| Behaviour | Viewer (browser, file preview) | Player (LMS or standalone) |
|---|---|---|
Provides API / API_1484_11 | No | Yes |
| Bookmark on return | None; starts from the beginning | Restored from cmi.location / cmi.suspend_data |
| Score and status | Shown on screen, then lost | Stored and reported |
| Typical symptom | "API not found" / "Unable to acquire LMS API" | None |
What happens in a viewer depends on how defensively the content was written. Some courses refuse to start. Many warn, then run with the quiz working but nothing saved. A few run silently with no sign the runtime is missing — the dangerous case, because the first evidence is an empty completion report after deployment. If you only need to inspect a package's contents, How to open a SCORM file covers what you can learn without a player and where that stops.
LMSSetValue("cmi.core.lesson_status", "completed") is ever sent, and whether the player accepts it, can only be seen with an API object in place and a log of the calls.How the player launches a SCO
The launch method matters because of how content finds the API. The specification does not hand the object to the content; the content goes looking for it. The standard discovery routine starts at the SCO's own window and walks upwards — window.parent, then that window's parent, to the top of the frame hierarchy — and if nothing is found, repeats the walk from window.opener, the window that opened this one as a pop-up. The reference algorithm gives up after a fixed number of hops.
That gives a player two places to put the object:
- Frame launch. The player's page holds the API object and loads the SCO into an
<iframe>. The content finds the object one or two parents up. This is the most common arrangement. - Window launch. The player opens the SCO with
window.openand keeps the API object in the opener. The content finds it viawindow.opener. This suits content that wants the full viewport, at the cost of pop-up blockers and learners closing the wrong window.
Two things break the discovery walk. Nesting depth: a player that wraps the SCO in several layers of frames, or a portal that embeds the LMS in a frame of its own, can push the object further away than the content will look. Origin: browsers block reads of window.parent and window.opener across domains, so a player that serves content from one domain while the API lives on the LMS domain produces "API not found" even though the object is right there. The player needs a bridge; the course cannot fix it from its side.
Once the object is found, the content calls Initialize("") and the launch method stops mattering. The player's remaining job here is cmi.entry: "ab-initio" for a fresh attempt, "resume" when there is saved state, which tells the content to read its bookmark.
What the player stores
The player stores whatever the content wrote to the data model, per learner, per SCO, and usually per attempt. Nothing is captured that the content did not explicitly send. The elements that reach reports are a small subset of the model:
| Purpose | SCORM 1.2 element | SCORM 2004 element |
|---|---|---|
| Completion / result | cmi.core.lesson_status | cmi.completion_status and cmi.success_status |
| Score | cmi.core.score.raw, .min, .max | cmi.score.scaled plus raw, min, max |
| Bookmark | cmi.core.lesson_location | cmi.location |
| Saved state | cmi.suspend_data (4,096 characters) | cmi.suspend_data (64,000 characters) |
| Time | cmi.core.session_time, summed into cmi.core.total_time | cmi.session_time, summed into cmi.total_time |
| Question detail | cmi.interactions.n.* (may be discarded) | cmi.interactions.n.* (must be kept) |
Three points trip people up. First, the player decides when data reaches the database: between Initialize and the first Commit everything may exist only in memory, and a crash then loses it — the content's design choice, not a player fault. Second, the player enforces the version's limits on write: a 1.2 player refuses or truncates suspend data beyond 4,096 characters, and the bookmark silently stops working for learners who get that far. Third, the player computes totals and roll-ups: total time is the sum of the session times it was given, and in 2004 the course-level status comes from the sequencing rules applied to each SCO's values. Two players given identical calls can show different course-level results if their roll-up logic differs — one reason the same package looks "broken" on one LMS and fine on another.
Running a player outside an LMS
Because the player has a defined contract, it does not have to live inside an LMS. Standalone players exist for the situations where an LMS is absent or inconvenient:
- Testing before upload. A test player provides the API object, logs every call, and shows the data model as the course writes to it — how you find out that a course sets status on the last page rather than after the quiz, before a client does.
- Delivery without an LMS. A hosted player can launch a package for learners with no LMS account, store the results itself, and optionally report them elsewhere. The package is unchanged; only the thing on the other side of the API differs.
- Embedding in another application. A portal or customer-training site can include a player component so off-the-shelf SCORM content runs inside it. The same frame-depth and same-origin rules apply, and are the usual source of trouble.
The test is the same as before: does it supply API or API_1484_11, answer the calls correctly, and persist on Commit? Anything that merely renders the launch file in a frame is a viewer with a longer name. Which platforms offer a genuine runtime, and how much of 2004 sequencing they implement, varies between products and releases, so verify with a small package rather than trusting a feature list. Hosting SCORM without an LMS goes through the options and what each does with the data.
Where SCORM Central fits
SCORM Central turns PowerPoint, PDF, and video files into SCORM 1.2 or SCORM 2004 4th Edition packages you can edit in its course builder, and its free tester shows the manifest checks and every runtime call a package makes before an LMS sees it. See how it works, or test a package free.