---
title: "Scorm H5p Wrapper"
description: "A Node application that takes an .h5p file and returns a SCORM zip. It bundles h5p-standalone so the content runs without an H5P server, adds a small adaptor that maps the H5P xAPI completion event onto SCORM score and status calls, and hands the whole thing to simple-scorm-packager. It runs as a local web app with an upload form, and there is a Docker image and an optional CSV log of successful packagings."
canonical_url: "https://scorm-tools.com/tools/scorm-h5p-wrapper"
last_updated: "2026-10-31T10:22:03.142Z"
---

A Node application that takes an `.h5p` file and returns a SCORM zip. It bundles h5p-standalone so the content runs without an H5P server, adds a small adaptor that maps the H5P `xAPI` completion event onto SCORM score and status calls, and hands the whole thing to simple-scorm-packager. It runs as a local web app with an upload form, and there is a Docker image and an optional CSV log of successful packagings.

The README is unusually fair about its own trade-offs, listing four disadvantages before any instructions: no shared caching of H5P libraries across packages, no in-LMS editing, no benefit from H5P core updates, and larger files. Take that seriously — it is the correct summary of when this approach is wrong.

Where it fits is narrow and real: an LMS with no H5P module, a client who must receive a self-contained file, or content that has to stay exactly as it was when it was signed off.

On maintenance, look past the repository's recent activity. Those pushes are Renovate and Dependabot branches; the `master` branch has not changed since January 2020, and the hosted instance the README points at no longer resolves. It packages fine, but the H5P runtime inside it is six years old.