Clearing up the naming first
Unity Playworks/Luna is the build tool — what you interact with inside a Unity project to turn a scene into a playable ad. Luna is the runtime/export engine that tool builds on top of. When someone says "Luna export," they're usually describing the same output a Playworks/Luna project generates, just named after the engine instead of the tool. Two people describing outwardly identical ZIPs as a "Luna export" and a "Playworks export" are most likely looking at the same kind of file, not two competing formats.
So the honest answer to "what's different between them" is: nothing, just because of the name used. What actually varies — and what's worth checking for instead — is the export's internal shape, independent of whichever name is on the label.
The two real shapes an export comes in
Regardless of what you call the tool that produced it, a Playworks/Luna export lands in one of two structural forms:
- Folder mode. A top-level
index.htmlthat references anengine/scripts.jsfile (and usually a handful of other loose asset files) by relative path. The HTML is a thin shell; the engine script and other assets sit alongside it as separate files, pulled in via normal browser requests as the page loads. - Single-HTML cache mode. A
cache/<id>/directory containing three files — typicallyscripts.js,jsons.js, andblobs.js— where every asset (images, audio, fonts, engine data) is already natively embedded as brotli-compressed, base64- or base122-encoded payloads baked directly into those scripts. There's no separate loose-file tree; everything the export needs is already inlined inside the cache scripts.
Both are legitimate, complete exports. Neither is the "old" or "new" format, and neither is specific to whether the source tool is called Playworks or Luna — which shape you get depends on how the export was configured at build time, not on naming.
How to tell which one you have
Don't guess from the filename — open the export and look at the folder structure:
- A
cachefolder with an id-named subfolder containingscripts.js,jsons.js, andblobs.jsmeans single-html cache mode. There may be a thin wrapperindex.htmltoo, but the real payload lives in that cache folder as encoded data, not as separate media files. index.htmlsitting next to anenginefolder with its own plainscripts.js, plus a visible spread of separate image, audio, or data files rather than three big encoded blobs, means folder mode.
The cache folder is the tell either way — its presence marks single-html mode; a plain engine/scripts.js with no cache folder marks folder mode.
Why the shape matters for conversion
Each shape needs a different asset-embedding path to end up as one compliant creative per ad network. Folder mode starts as loose files referenced by relative URLs, so producing a single self-contained HTML file (required by AppLovin, Meta, Unity Ads, and Vungle) means reading each separate file and inlining it as a data URI or a runtime asset shim. Single-html cache mode starts already encoded and self-contained, but in a network-agnostic wrapper — for networks with tighter size limits, or that require base64 specifically over base122, that inlined cache sometimes needs decompressing and re-encoding rather than copying through as-is. The end goal is the same per network either way; only the starting material and transform differ.
How PlayableKit handles both
From the user's side, this distinction is invisible. PlayableKit detects which shape an uploaded export is in automatically, routes folder-mode exports through the file-inlining path and cache-mode exports through the decode/re-encode path, and produces the same kind of output either way: a separately packaged, network-compliant creative for each network selected, with correct click-through wiring, asset encoding, and package shape per network's actual rules. You don't need to know which shape your export is in before uploading, or convert one shape to the other manually first.
| Signal | Folder mode | Single-html cache mode |
|---|---|---|
| Top-level files | index.html + engine/ | cache/<id>/ |
| Media assets | Separate loose files by relative path | Embedded brotli+base64/base122 |
| PlayableKit's conversion path | Inline loose files into one HTML | Decode cache, re-encode per network |
The short version
"Playworks export" and "Luna export" are two names for the same thing, not two different formats. The real fork in the road is folder mode vs. single-html cache mode, and you can tell which one you have in about ten seconds by checking for a cache/<id>/scripts.js path versus a plain engine/scripts.js. Either way, getting that export compliant on every ad network is the same category of problem — just solved with a different asset-embedding path depending on the shape, which is exactly what PlayableKit's pipeline handles automatically once you upload.