repairtroubleshootingscormcompletionchecklist

Repairing a Broken SCORM Package: A Practical Checklist

by The ScormEdit Team·March 26, 2026·9 min read

A broken SCORM package fails in one of three places: it will not upload, it uploads but will not launch, or it launches but never reports completion. Each has a small set of usual causes, and almost all of them are fixable without the original source file. This is the checklist to work through, top to bottom, when a package is misbehaving.

Stage 1: It will not upload

Check the manifest is at the archive root

The single most common cause of a rejected package is the manifest in the wrong place. SCORM requires imsmanifest.xml at the very top of the zip. If someone zipped the course folder instead of its contents, the manifest ends up at CourseName/imsmanifest.xml — one level too deep — and the LMS reports it as missing even though it is right there. Open the zip and confirm imsmanifest.xml is at the root, not inside a subfolder.

Zip the contents of the course folder, not the folder itself. The manifest must sit at the archive root or virtually every LMS will reject the package with "imsmanifest.xml is missing."

Check the manifest is valid XML

If the manifest is at the root but still rejected, the XML may be malformed: an unclosed tag, a stray character, a missing required element, or a stripped UTF-8 byte-order mark that some parsers expect. SCORM manifests are validated against published schemas, so a structurally invalid manifest fails even if it looks fine at a glance.

Check for files declared but missing

The manifest lists every file the package contains. If it declares a file that did not make it into the zip — a deleted asset, a renamed page — strict LMSes reject the package outright. Reconcile the file list in the manifest against what is actually in the archive.

Stage 2: It uploads but will not launch

Check the launch href points at a real file

A package that imports cleanly but shows a blank screen or an endless spinner usually has a launch-href problem. The resource in the manifest names an entry page; if that page does not exist, or points at the wrong file, the course never starts. Confirm the href in the manifest matches an actual file in the package — for Storyline output this is typically the LMS launch page, not the standalone one.

Check that asset paths are relative

The LMS hosts the course from a URL it chooses, not from wherever it was authored. If pages reference assets by absolute or machine-specific paths, those references break the moment the LMS serves the course from somewhere else. Asset paths inside the package should be relative.

Open the browser console while the course tries to launch. A burst of 404s points straight at the broken paths or missing files causing the blank screen.

Stage 3: It launches but never reports completion

This is the most painful failure because the course appears to work — the learner finishes, sees the final slide, and the LMS still shows "incomplete" or "not started." It is a runtime problem, not a packaging one, but it gets reported as a broken package. The usual causes:

The course cannot find the LMS API. SCORM content locates the LMS by walking up the chain of parent and opener windows. If that handshake fails — often an LMS frame or pop-up configuration issue — the course runs but talks to nobody.
The course never commits or finishes. If the run-time adapter does not call the commit and finish steps, the LMS may discard the session, so the completion the learner earned never gets saved.
The wrong status is being set. Under SCORM 1.2 everything funnels through one lesson-status field; if the course leaves it as "incomplete" or sets the wrong value, the LMS believes the learner is not done.
The resume data overflowed. On long SCORM 1.2 courses, exceeding the 4096-character suspend-data limit can corrupt the saved state and reset progress, which reads as "they never finished."

Completion failures are easy to miss because nothing errors visibly. Test in an environment that logs the SCORM run-time calls — SCORM Cloud is the standard choice — so you can see whether the course actually sends a "completed" status and a successful commit.

The full repair checklist

Confirm imsmanifest.xml is at the archive root, named exactly that, lowercase.
Confirm the manifest is well-formed XML and validates against the SCORM schema.
Reconcile declared files against the files actually in the zip.
Confirm the launch href in the manifest points at a real entry page.
Confirm asset paths are relative, not absolute or machine-specific.
Upload to SCORM Cloud or a test LMS and watch the console for 404s.
Drive the course to the end and confirm it sends a completion status and a successful commit.
For long courses, check whether suspend data is overflowing the 1.2 limit.
Re-zip correctly — contents at the root, manifest on top — before final upload.

Most "broken SCORM" tickets are not broken content. They are a manifest in the wrong place, a path the LMS cannot follow, or a completion call that never fires.

Diagnosing and repairing in the browser

ScormEdit includes a free validator that runs this checklist for you: it checks the manifest location and validity, flags declared-but-missing files, verifies the launch entry point, warns about absolute paths and suspend-data risk, and offers one-click fixes like moving the manifest to the root and repackaging correctly. You can confirm a package is healthy — and repair the common breakage — from the published .zip, without unzipping anything or editing a line of XML.