imsmanifest.xml missing or not found: fixes

What the error actually means

An "imsmanifest.xml missing" or "imsmanifest.xml not found" error almost never means the file does not exist. It means the LMS opened the zip, looked at the top level for a file named exactly imsmanifest.xml, and did not find one there. Usually the manifest is one folder down, misnamed, or the upload is not a SCORM zip at all.

The wording varies by platform — "missing manifest", "not a valid SCORM package", "no manifest at root", "could not find imsmanifest.xml" — but the check behind every one of them is the same. SCORM defines the package as a zip with imsmanifest.xml at its root; the importer reads that one file first to learn what the course is called, which file to launch and which version of the runtime to expect. If it cannot read it, it has nothing to import, so it stops there. That is why the message says nothing about the rest of your content: the importer never got that far.

The causes below are in rough order of frequency; the first two account for most cases.

Why is imsmanifest.xml not at the root?

The most common cause is how the zip was made. If you right-click a folder called my-course and compress it, Windows and macOS both produce a zip whose top level contains a single folder, my-course/, with the manifest inside it. The LMS looks at the top level, sees a folder and no manifest, and reports it missing. The package is one level too deep.

Wrong — compressed the folder:
my-course.zip
└── my-course/
    ├── imsmanifest.xml
    ├── index.html
    └── ...

Right — compressed the folder's contents:
my-course.zip
├── imsmanifest.xml
├── index.html
└── ...

Fix: open the folder, select everything inside it, and compress that selection. On Windows: select all, right-click, Send to, Compressed (zipped) folder. On macOS: select all, right-click, Compress. From a terminal, run the zip command from inside the folder: cd my-course && zip -r ../my-course.zip .

A close relative is the macOS zip that contains a __MACOSX folder plus one nested folder. Finder adds __MACOSX to store file metadata; most importers ignore it, but it is a sign the zip was built by compressing a folder rather than its contents, and the real problem is the nested folder beside it. Rebuild the zip from inside the folder and the __MACOSX entry stops mattering; if an importer does object to it, zip -r -X ../my-course.zip . omits the metadata entirely.

A third variant: an authoring-tool export was unzipped, edited, and re-zipped, and the manifest is now under the folder the files were extracted into. Any time a package has been through an extract-and-recompress cycle, assume the nesting changed until you have looked.

Wrong file name or case

The specification requires the file to be named imsmanifest.xml, all lower case, with that exact extension. The following all exist in the wild and all fail on a strict importer:

• IMSManifest.xml, ImsManifest.xml or IMSMANIFEST.XML — same letters, different case;
• imsmanifest.XML — right name, upper-case extension;
• manifest.xml — a plausible name, but not the one the importer looks for;
• imsmanifest.xml.txt — a text editor saved it with a hidden second extension, which Windows Explorer shows as imsmanifest.xml when "hide extensions for known file types" is on;
• imsmanifest (1).xml — a browser download renamed a duplicate.

Case matters because most LMSs run on Linux, where IMSManifest.xml and imsmanifest.xml are two different files. A package that imported fine on a Windows-hosted test server can fail on the production LMS for this reason alone, which makes the problem look intermittent when it is not.

Fix: rename the file to exactly imsmanifest.xml and rebuild the zip. To catch the hidden-extension case, turn on file extensions in Explorer, or list the zip from a terminal, which shows the true name.

It is not a SCORM package

Several other e-learning formats are also delivered as a zip of HTML files, and an LMS import screen set to SCORM will reject every one of them with a missing-manifest error, because none of them has an imsmanifest.xml. Open the zip and look for the descriptor file at the top level:

The last row catches people most often. Authoring tools offer "HTML5" or "Publish for web" alongside "SCORM", and the two outputs look identical from the outside: same size, same folder names, same index.html. Only the SCORM export carries the manifest and the runtime wrapper that talks to the LMS. If the zip has no XML descriptor at all, re-zipping will not help; go back to the tool and publish for SCORM. A minimal SCORM package, file by file shows what the complete set of files should look like.

One more possibility is a file that is not a zip. Importers check the file's contents, not its extension. A .rar or .7z archive renamed to .zip typically produces the same missing-manifest or "not a valid package" message, because the importer could not open the archive to look inside it. A real zip begins with the bytes PK; a RAR begins with Rar!. If in doubt, extract the archive with a normal tool and re-zip the contents.

The manifest exists but will not parse

Some importers report a manifest they could find but could not read as "missing", because a manifest that fails XML parsing yields no package information, which is the same outcome. The file is at the root, named correctly, and the error persists. Common reasons:

• A hand edit left a tag unclosed, or a & in a title was not escaped as &. One bad character invalidates the document.
• The adlcp: or imsss: prefix is used on an element but the matching xmlns:adlcp or xmlns:imsss declaration was deleted from the root <manifest> element while "cleaning up" the header.
• Stray characters before <?xml, or an encoding that does not match the declaration. Nothing may precede the XML declaration, not even a blank line.
• A find-and-replace across the whole package changed a path, an identifier, or turned a straight quote into a typographic one.

Fix: open imsmanifest.xml in a browser. It will refuse to render malformed XML and tell you the line and column of the first error, which is normally enough. Correct it, re-zip, and re-import. If the manifest parses but the import fails with a different message, the problem has moved on to why a SCORM package fails in the LMS, which covers launch and runtime errors.

The 30-second check before upload

Every cause above is visible without an LMS. Before uploading, open the zip and read its top level. Do not extract it; just look. On Windows, double-click the zip in Explorer. On macOS, use the terminal, because Finder extracts rather than browses. From any terminal:

unzip -l my-course.zip | head -n 12

Archive:  my-course.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
     2841  2026-10-30 09:14   imsmanifest.xml
    11206  2026-10-30 09:14   index.html
     4096  2026-10-30 09:14   scorm_api.js
      ...

Four things to confirm, in order:

1. imsmanifest.xml appears in the listing with no folder prefix in front of it. If the first entries are all my-course/..., the package is nested.
2. The name is exactly imsmanifest.xml, lower case, no second extension, no "(1)".
3. The launch file named in the manifest's <resource href="..."> is also in the listing, at the path the manifest gives.
4. The listing is a real zip listing. If unzip reports "cannot find zipfile directory" or "End-of-central-directory signature not found", the file is not a zip.

If all four hold and the LMS still reports the manifest missing, open the manifest in a browser to check it parses. That sequence covers every cause in this article and is the first thing any support team will ask you to do anyway.

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.