A .whl file is Python's built-distribution format: a ZIP archive containing a package's modules already laid out as they should appear in site-packages, plus a .dist-info directory of metadata. Installing one is a copy rather than a build, which is what made pip installs fast and predictable.
Private for supported formats — processed in your browser
Convert supported files
Runs on your device
+
Drop WHL files here
Batch files can each use a different output. Nothing uploads for local conversions.
Working inputs include camera RAW, browser-local audio/video, PDF, CBZ/CBR comics, office documents, ebooks, markup, 3D models, structured text, images, and archives.
PEP 427 defined the wheel format in 2012 to replace the egg format and to end the practice of running arbitrary setup.py code at install time. PEP 425 gave wheels their compatibility tags, the manylinux series of proposals made portable Linux binary wheels possible from 2016 onward, and PEP 660 extended the format to editable installs in 2021.
How WHL works
The filename itself is structured metadata: distribution, version, an optional build tag, then Python, ABI, and platform tags separated by hyphens.
A .dist-info directory holds METADATA, WHEEL, RECORD, and optionally entry_points.txt describing console scripts.
RECORD lists every installed file with a SHA-256 hash and byte size, so installations can be verified and cleanly uninstalled.
Pure-Python wheels use the py3-none-any tag and work everywhere; binary wheels pin a specific ABI and platform.
The format is deliberately install-by-copy: no code from the package runs while it is being installed.
When to use WHL
Reading a package's METADATA and dependency list without installing it into an environment.
Extracting a single module or data file from a downloaded wheel.
Auditing what a binary wheel would place on disk, including bundled shared libraries.
Repackaging a wheel's contents for an air-gapped system that expects a plain archive.
Strengths and limitations
Strengths
Installation is a file copy, so it is fast and cannot execute setup-time code.
RECORD hashes make installs verifiable and uninstalls complete.
Compatibility tags make it obvious whether a wheel matches an interpreter before download.
An ordinary ZIP inside, so inspection needs nothing beyond an archiver.
Limitations
Binary wheels are tied to a specific Python ABI and platform, so the file matrix grows quickly.
Bundled shared libraries can collide with system copies at import time.
The filename encodes information that is easy to get wrong when a wheel is renamed by hand.
Compatibility
pip, uv, Poetry, and every modern Python installer consume the format on Windows, macOS, and Linux, and any ZIP tool opens one directly. Novus Convert reads the ZIP in the browser and writes the entries out as ZIP or TAR; no Python code from the package is imported or run.
METADATA carries the name, version, dependencies, and long description, WHEEL records the format version and tags, and RECORD holds per-file hashes. All three are ordinary files and survive extraction unchanged.