The 4096-Character suspend_data Limit: Why Learners Lose Their Progress (and How to Fix It)

Here is a support ticket every LMS admin eventually gets: "I was 80% through the course, came back the next day, and it started me over from the beginning." The learner did nothing wrong, the LMS is working as designed, and the most likely culprit is a 25-year-old size limit on a single field: suspend_data.

What suspend_data actually is

When a learner pauses partway through a course, the content has to remember where they were: which slide, which questions answered, which branches taken, which variables set. It serializes all of that into a string and hands it to the LMS to store in a field called cmi.suspend_data. When the learner returns, the course reads that string back and restores their state. That is how "resume where you left off" works.

The 4096-character wall

The SCORM 1.2 specification limits suspend_data to 4096 characters. That sounds like a lot until you realize a rich course can easily need more: every visited slide, every quiz answer, every variable, every branch choice adds to the string. Once the course tries to store more than 4096 characters, the data is truncated. On return, the course reads back a corrupted or incomplete resume state — and the safest thing it can do is start over.

It is widely regarded as an unfortunate but real constraint of the 1.2 spec — small, arbitrary by modern standards, and a frequent source of "the course keeps restarting" complaints in tools like Storyline and Rise 360.

Who hits it hardest

• Long courses — more slides means more state to remember.
• Branching scenarios — every decision point adds to what must be tracked.
• Quiz-heavy courses — storing answers and attempt history is expensive.
• Courses with many variables — each tracked variable contributes to the string.

How to fix it

Fix 1: Move to SCORM 2004 (the usual answer)

SCORM 2004 raises the suspend_data limit to roughly 64000 characters — about sixteen times more headroom. For most courses that overflow 1.2, that is the difference between reliable resume and constant restarts. This is exactly why teams with resume problems migrate from 1.2 to 2004. The catch: your LMS must support 2004, so confirm that first.

Fix 2: Raise the limit in package settings (if your platform allows)

Some SCORM hosting platforms let you raise the maximum suspend_data size in the package properties — for example, lifting it from 4096 to 64000. If your environment exposes this, it can resolve the problem without re-authoring. But it depends on the LMS honoring the larger size, so test it.

Fix 3: Reduce how much state the course stores

At authoring time you can shrink the footprint: fewer tracked variables, less granular bookmarking, splitting a giant course into smaller SCOs so each one’s resume state stays under the limit. This needs the source file, which is exactly the situation many maintainers are not in.

How to confirm this is your problem

1. Reproduce it: go partway through the course, exit, and relaunch. If it restarts instead of resuming, suspect suspend_data.
2. Check the SCORM version: if the package is SCORM 1.2 and the course is long or branching, the 4096 limit is the prime suspect.
3. If you can inspect runtime calls (SCORM Cloud’s debug log, or your LMS), watch the size of the suspend_data being written — if it is near or over 4096, you have found it.

A course that cannot resume is a course learners abandon. For long compliance content, fixing the resume limit is not a nicety — it is the difference between completion and churn.

Diagnosing and fixing without the source file

ScormEdit flags the SCORM version of your package and warns when a course is at risk of the 1.2 suspend_data limit — and because splitting an oversized course into smaller modules is one of the cleanest fixes, it can do that split in the browser, repairing navigation and producing valid packages whose per-module resume state fits comfortably under any LMS limit. No source file, no re-authoring.