This specification defines the PortableWeb format (.pweb), a file format for
self-contained, sandboxed, interactive documents. A .pweb file packages HTML, CSS,
JavaScript, and media into a single ZIP archive, intended to be opened by a compatible viewer
in an isolated execution environment, without requiring network access or server infrastructure.
The format provides an archival guarantee: a bundle declaring a given spec_version
in its manifest must remain openable by any future viewer that claims support for that version.
This specification covers five areas: the container and packaging format, the manifest schema and capability declaration model, viewer conformance requirements and security sandboxing, the per-bundle storage model, and the inter-bundle communication model. A companion Implementation Guide and Conformance Test Suite are maintained alongside this document.
This is an early Community Group Draft. The specification is being developed in the W3C Portable Web Content Format Community Group. Feedback is welcome via GitHub Issues.
An IETF Internet-Draft covering the same material is available at draft-selvaraj-portableweb-format-01.
Implementations and tooling are maintained at github.com/portableweb.
Sections 4–6 (Viewer Conformance, Storage Model, Inter-Bundle Communication) are placeholders. They will be developed after the container and manifest sections (Sections 2–3) are stable.
There is no widely-adopted file format for interactive content that the user owns and that lasts. URLs depend on hosting and suffer link rot. PDFs cannot carry meaningful interactivity. Progressive Web Apps install from URLs and depend on server infrastructure. Web Bundles were explored and subsequently removed from browsers.
PortableWeb addresses this gap. A .pweb file is a ZIP archive containing an HTML
entry point, associated assets, and a manifest. It is opened by a compatible viewer which
provides a sandboxed execution environment. The bundle is the unit of preservation.
spec_version must remain openable by any compatible future viewer.
Features are never removed from a published version.
A bundle declaring spec_version: "1.0" in its manifest MUST remain openable
by any future viewer that claims support for v1.0 bundles. Features MUST NOT be removed
from a published spec version. New features ship in new spec versions; old bundles never
break.
A .pweb file is a ZIP archive conforming to
ISO/IEC 21320-1 (Document Container File),
with the additional constraints defined in this section.
The registered file extension is .pweb.
The media type is application/vnd.portableweb+zip.
A conforming bundle MUST contain the following entries at the archive root:
mimetype — MUST be the first entry in the archive, stored uncompressed
(STORE method, compression level 0), with no extra fields. Its content
MUST be the ASCII string application/vnd.portableweb+zip with no trailing
newline. This placement allows the file(1) command and other magic-byte
sniffers to identify the format by reading the first ~80 bytes of the file.
manifest.json — the bundle manifest (see ).
entry field.
The following paths are reserved and MUST NOT be used for content files:
mimetypemanifest.jsonMETA-INF/.well-known/
Viewers MUST treat .pweb files as untrusted content before validation.
Implementations MUST defend against ZIP-based attacks including:
../ sequences in entry namesSee the container test cases for conformance tests covering these requirements.
The manifest is a UTF-8 encoded JSON document stored at manifest.json in the
archive root. It declares the bundle's identity, entry point, and the capabilities it requires.
spec_version"0.1"
for bundles conforming to this draft.id"org.example.my-bundle". Used for storage isolation.versiontitleentry"index.html".descriptionauthorcreatediconpermissionsrights
Capabilities are declared upfront in the manifest's permissions field. The
viewer enforces a default-deny policy: any capability not declared in the manifest is denied
at runtime. The viewer prompts the user on first open based on declared capabilities; the
bundle cannot request additional permissions at runtime.
The following capabilities are defined:
| Capability | Default | Description |
|---|---|---|
storage | isolated | Access to per-bundle isolated storage |
internet.read | false | Outbound network reads from declared domains |
internet.write | false | Outbound network writes |
camera | false | Camera access |
microphone | false | Microphone access |
geolocation | false | Device geolocation |
inter-bundle | false | Communication with other bundles over local network, Bluetooth, or WiFi Direct |
The full capability schema, including field shapes for domain lists and justification strings, will be specified as this section matures.
This section is a placeholder. It will be developed after the container and manifest sections are stable. See the sandbox test cases for the planned conformance coverage.
This section will define the requirements a viewer MUST meet to be considered conformant, including:
bundle://<id>/) with no access to the viewer's storage, DOM,
or execution context.This section is a placeholder. It will be developed after the viewer conformance section is stable. See the storage test cases for the planned conformance coverage.
This section will specify:
id.exportData() and importData() portability hooks that
bundles using storage MUST expose..pweb with
current state baked in.This section is a placeholder. It will be developed after the storage model section is stable. See the inter-bundle test cases for the planned conformance coverage.
This section will specify a permission-gated channel enabling bundles to communicate locally via Bluetooth, WiFi Direct, or local network. This makes offline multiplayer, peer-to-peer, and collaborative interactive experiences possible without any server infrastructure — a capability not addressed by any existing format or specification.
Key areas to be specified: