What converting a Word document to SCORM produces
To convert a Word document to SCORM is to wrap its content as a launchable course — a SCO — that an LMS can import, display, and track. The text and images become HTML pages; a manifest lists them in order; and a small amount of JavaScript reports when the learner has finished.
The .docx itself is never what the LMS runs. Conversion re-flows the document into web content and adds the two things a Word file does not have: imsmanifest.xml, which tells the LMS what the course contains and in what order, and the runtime code that talks to the SCORM API. Most converted documents become a single SCO — one launchable unit — though a long document split into modules can become several. What the LMS stores at the end is not "the document"; it is whatever that runtime code decided to report.
That distinction is the whole reason conversion takes more than "export to HTML". A pile of HTML pages will display in an LMS but track nothing. A SCORM course displays and reports completion, and getting the reporting right is where the work is.
Headings become the outline
The single most important thing you can do before converting is to use Word's real heading styles. When you mark a line as Heading 1 or Heading 2 — rather than just making it big and bold — you are giving the document a structure a converter can read. That heading tree becomes the course outline: the sections a learner navigates, the page breaks, and the entries in any on-screen menu.
A document that is one long run of Normal text with manually emboldened lines carries no structure at all. A converter has nothing to split on, so it produces a single endless page. The fix is in Word, not in the converter: apply Heading 1 to top-level sections, Heading 2 to sub-sections, and keep the levels consistent. The same discipline applies whichever source you start from — it is exactly what makes converting a PowerPoint deck predictable, where each slide is already a discrete unit.
Tables, images, and formatting
Not everything in a Word document survives the trip to HTML cleanly. Knowing what travels well saves a lot of rework.
- Tables usually convert to HTML tables and hold up well for genuine tabular data. Tables used purely for layout — two columns to place an image beside text — often collapse on narrow screens. Reserve tables for data.
- Images are embedded into the package, so every large image adds to its size and load time. Resize and compress them in Word (or before you paste them) to sensible screen dimensions; a 4,000-pixel photo helps no one inside a 700-pixel frame.
- Fancy formatting — text boxes, SmartArt, WordArt, drawn shapes, and equation objects — frequently does not map to HTML and may be dropped or flattened into a picture. If a diagram matters, export it as a clean image yourself rather than trusting the converter to rasterise it.
- Fonts and colour from Word are not guaranteed on the web. Content typically re-flows into web-safe styling, so do not rely on an exact visual match with the original document.
Add alternative text to every meaningful image in Word before converting. It carries into the HTML, and it is the difference between an accessible course and one a screen-reader user cannot follow.
Splitting long sections
A forty-page policy document converted as one scrolling page is technically a course, but a poor one. Learners lose their place, and you get one blunt "viewed / not viewed" signal for the whole thing rather than any sense of progress through it.
Splitting the document into screens — usually one per Heading 1 or Heading 2 — fixes both problems. Each screen is a natural checkpoint, the course can remember which screen a learner reached, and resume becomes meaningful. Bookmarks and per-page state are held in the runtime's suspend_data, and keeping sections reasonably sized keeps that state small, which matters because SCORM 1.2 caps it at roughly 4 KB. A course that tries to remember granular state across a hundred un-split pages is the kind that quietly stops resuming correctly.
Aim for screens a learner can absorb in a minute or two: long enough to be a coherent idea, short enough that finishing one feels like progress.
Do you need a knowledge check?
A converted Word document is, by default, passive: the learner reads, and the only thing the course can honestly report is that every screen was viewed. For a reference document or an information rollout, that is often exactly enough. When you need evidence that someone understood the material — not just that they scrolled past it — you add a knowledge check.
A few questions at the end turn "viewed" into "passed or failed", and those are different facts. SCORM 2004 records them in separate fields — completion_status for whether the learner finished and success_status for whether they passed — so a learner can be completed and failed at once. SCORM 1.2 collapses both into a single status. Which behaviour you want decides more than it first appears; the trade-off is laid out in completion status vs success status.
Even a short check also gives you a score to report, which many compliance rules require. If all you need is proof of attendance, skip it; if you need proof of understanding, it is the only honest way to get it.
Completion and testing
Before you build, decide the completion rule explicitly, because "it just knows" is not one of the options. The two common rules are completed when every screen has been viewed and completed when the knowledge check is passed. The first suits documents; the second suits anything you must certify. Your choice also nudges the SCORM version: a pure viewed-all-pages document is happy in SCORM 1.2, while separate completion and pass reporting is cleaner in 2004. If you are unsure, which SCORM version should I use walks the decision in a minute.
Then test before you deliver — on the platform you actually use, not just in a preview. Upload the package, take the course as a learner, finish it, and confirm the LMS shows the completion (and the score, if there is one). Close the tab abruptly after finishing and reopen to check the status held. The runtime log is where the truth lives: it shows the exact calls the course made, so if the LMS says "incomplete" when you know you finished, the log tells you which call went missing.
Convert, split sensibly, decide the rule, and test on the real platform, and a Word document becomes a course that reports what actually happened rather than what you hoped it would.
Where SCORM Central fits
SCORM Central converts files you already have — PDF, PowerPoint, Word, or video — into SCORM 1.2, SCORM 2004, cmi5, or xAPI, and shows you the manifest, the full runtime log, and a conformance report on every build, so you can see exactly what a package will report before an LMS does. See how it works, or start with one file.