What this checks
- Package structure — that
imsmanifest.xmlexists at the root and is valid XML, and which SCORM version it is (1.2 or 2004). - Manifest correctness — that items point to real resources and that every file the manifest references is actually inside the zip.
- Tracking readiness — whether the content calls the SCORM run-time API, the usual reason completion or score never records.
SCORM 1.2 vs SCORM 2004 — which do I have?
SCORM 1.2 is the older, most widely supported version — simple completion and
score tracking, and what most LMSs accept by default. SCORM 2004 (2nd–4th Edition)
adds sequencing and navigation rules and a richer data model. The validator reads the version
straight from your manifest's <schemaversion>. If you're unsure which to publish,
1.2 is the safest default unless you specifically need 2004's sequencing.
Common reasons a SCORM package won't work
- Zipped the folder, not the contents.
imsmanifest.xmlmust be at the top level of the zip. If it's one folder deep, most LMSs reject it. - Missing files. The manifest references files that didn't make it into the zip — blank screens or launch errors.
- Broken references. An item's
identifierrefdoesn't match any resource, so nothing launches. - No API calls. The content was exported as plain web content, not a tracked SCO, so the LMS never sees completion.
- Case-sensitive paths. Filenames that work on Windows but break on a Linux-hosted LMS.
Frequently asked questions
Is my SCORM file uploaded anywhere?
No. Everything runs in your browser with JavaScript — the package never leaves your computer.
Does a "valid" result guarantee it works in my LMS?
It means the package is structurally sound and should launch and track. Individual LMSs have their own quirks, so a valid result is a strong signal, not an absolute guarantee.
Can it check xAPI (Tin Can) or cmi5 packages?
It detects them and tells you they aren't SCORM. Full xAPI/cmi5 validation isn't supported yet.