Is the package valid?
The imsmanifest.xml is validated against the schema for its declared standard — SCORM 1.2 or 2004 — with errors in plain English, not schema jargon.
FREE TOOL
Test a SCORM package before the LMS does.
Upload a SCORM zip and watch every runtime call it makes — Initialize, SetValue, Commit — with manifest checks alongside. Free, in the browser, no account.
What does it actually report?
Launch the course and see the full call log per attempt: every SetValue, every Commit, in order, with the values the LMS would receive.
Will completion arrive?
The checks that catch real-world failures: score set before completion, suspend data under the limit, commit cadence that strict platforms tolerate.
WHAT IT CHECKS
Three questions, answered before anyone else sees the file.
Will the LMS accept the package at all?
Most import failures are manifest failures, and they happen before a learner ever launches the course. The tester reads imsmanifest.xml, checks it against the schema for the version the package claims, and reports what is wrong in words rather than XSD error paths. The usual culprits: a resource href that points at a file not in the zip, a missing or duplicated identifier, a manifest nested inside a folder instead of sitting at the root of the zip, or a SCORM 2004 manifest declared with SCORM 1.2 namespaces. Any one of them stops the import cold. The manifest, explained covers the structure in detail.
What does the package actually send?
This is the part no authoring-tool preview shows you. The tester launches the course against a real SCORM runtime and records the conversation: every Initialize, GetValue, SetValue, Commit and Terminate, in order, with the exact string values that would reach an LMS and the return code for each call. A course that never sets cmi.completion_status, or sets it and then never commits, is obvious in ten seconds in a log and invisible everywhere else.
Will completion and score survive?
Beyond the raw log, the tester applies the checks that separate a package that works on your desk from one that works on a customer's platform: is score written before status, so a platform that evaluates a mastery score at the moment status arrives has the number it needs; is there a Commit after the status writes, before the fragile exit; is cmi.suspend_data inside the cap for the declared version — 4,096 characters for SCORM 1.2, 64,000 for 2004; and is the commit cadence something a throttling platform will tolerate rather than rate-limit.
READING THE LOG
What a broken package looks like.
Two logs from courses that behave identically for the learner. One reports; one does not.
Healthy. Score before status, a commit straight after, exit set before termination:
SetValue("cmi.score.scaled", "0.84") → "true"
SetValue("cmi.success_status", "passed") → "true"
SetValue("cmi.completion_status", "completed") → "true"
Commit("") → "true"
SetValue("cmi.exit", "normal") → "true"
Terminate("") → "true"
Broken. Status written first, no commit before the learner closes the tab, and a final write that lands after the session has already closed:
SetValue("cmi.completion_status", "completed") → "true"
SetValue("cmi.score.scaled", "0.84") → "true"
Terminate("") → "true"
SetValue("cmi.score.raw", "21") → "false" error 133: store after termination
Both courses look finished to the learner. The second one loses the score on any platform that evaluates mastery when status arrives, and loses everything on any platform that buffers values until a commit. This is the single most common cause behind courses that lose completions, and it is only visible in the call log.
Once you can read the log, the same discipline applies to every package you ship. The SCORM API explained walks through each method and the error codes worth knowing, and testing a SCORM package before upload is the full pre-flight checklist.
THE ALTERNATIVES
Ways to test a SCORM package, compared.
| Approach | What it tells you | What it costs you |
|---|---|---|
| Authoring-tool preview | That the content renders | Nothing — but it stubs the SCORM API, so it cannot fail on a missing commit or a late write |
| Upload to the real destination LMS | The truth, for that one platform | You need access, and a failure is often already a customer-visible one |
| A hosted sandbox with an account | Runtime behaviour against a reference player | Signup, and usually a registration or upload allowance |
| Browser developer tools | Whatever you instrument yourself | You have to wrap the API object by hand and know what to look for |
| This tester | Manifest validity plus the full runtime call log | Nothing, and no account — results are not saved between sessions |
None of these replaces testing on the destination platform when you know what it is. What a pre-flight check buys you is that the package is already correct when it gets there, so a failure points at the platform rather than at your zip — and platform quirks are their own subject, covered in runtime behaviour profiles.
WHY THIS EXISTS
"It worked in the authoring tool" is not a test.
Most SCORM problems only show up at runtime, in someone else's LMS, after the course has shipped. A five-minute check of the actual call log catches lost completions, missing scores, and bookmark failures while they are still your problem to fix quietly — not a support ticket from a customer.
The tester runs in the guest workspace — nothing to install and no signup. If you want to keep the results, replay a package against saved LMS behaviour profiles, or fix the source file and rebuild, that is what the full product does.
Questions
Do I need an account to test a SCORM package?
No. The tester runs in a guest workspace in your browser. There is nothing to install and no signup step.
Which SCORM versions can it test?
SCORM 1.2 and SCORM 2004 (2nd, 3rd and 4th Edition). The manifest is validated against the schema for whichever version the package declares.
What does the tester actually check?
Three things: that imsmanifest.xml is valid against its declared schema, what the package sends at runtime — every Initialize, GetValue, SetValue, Commit and Terminate call in order — and whether completion and score will survive the way real platforms behave.
Why did my course work in the authoring tool but not in the LMS?
Authoring-tool previews usually stub the SCORM API rather than enforcing it. They do not fail on a missing Commit, a status written before a score, a value written after Terminate, or suspend data over the version cap. Those only appear against a real runtime, which is what the call log shows you.
Is my package uploaded anywhere?
The package is processed in the guest workspace for the session so it can be launched and its runtime calls recorded. Saving results between sessions is what an account is for.
How big a package can I test?
Typical converted decks, documents and single-SCO courses are fine. Very large media-heavy packages are better tested after trimming the media, since the runtime behaviour is what is being checked, not playback.
Start with one file.
Upload something you already have and see it as a package, with the conformance report and the runtime log alongside it.
→ upload handbook.pdf parsing … 14 sections building manifest … validating … 0 errors, 2 notes ✓ handbook-scorm2004.zip ✓ preview link ready