Python Wheel Viewer and WHL Extractor

Open a Python wheel, read its packaged code and inspect its distribution metadata.

Drop your .whl file here
Choose file

⚠ Drag-and-drop upload could not load — an ad blocker is most likely blocking it. Please disable your ad blocker and reload the page to upload a file.

Open WHL without installing it

Upload a .whl to browse its Python modules, type stubs, configuration, resources and native libraries. Processing runs on our servers. No pip install, imports, dependency downloads, entry points or .pth hooks are executed. You do not need a Python environment matching the wheel's platform.

Try a wheel example

Download the small wheel_demo example and drop it above. It includes a namespace package, exact Python source, a type stub, a JSON resource, an extra, two compatibility tags and .data installation categories. Its source is supplied under this project's license.

wheel_demo-1.0-py2.py3-none-any.whl/
  WHEEL-SUMMARY.txt
  wheel.json
  files/demo/hello.py
  files/demo/hello.pyi
  files/demo/settings.json
  files/wheel_demo-1.0.dist-info/METADATA
  files/wheel_demo-1.0.dist-info/WHEEL
  files/wheel_demo-1.0.dist-info/RECORD
  files/wheel_demo-1.0.dist-info/entry_points.txt
  files/wheel_demo-1.0.data/data/share/wheel_demo/readme.txt

Start with WHEEL-SUMMARY.txt for name, version, Python requirement, declared dependencies and extras, all supplied WHEEL tags, root installation category and observed native content. Read wheel.json in the structured viewer. Browse or download individual original members, or download the complete result ZIP. Namespace paths and .data categories stay as packaged; nothing is written to host installation directories.

Source-present, stub-only and native-only wheels

Most pure-Python wheels include ordinary .py files that can be read directly. Type stubs (.pyi) describe interfaces. Platform wheels can contain .so, .pyd libraries or native executables: these remain downloadable, but original Python source cannot generally be recovered from native code. A wheel without Python source can still provide useful metadata and resources.

Wheels rarely include Python bytecode. When a valid .pyc member is present, the existing pycdc recovery path supports bytecode through Python 3.10 and places available source under recovered/<member-path>/source.py. Unsupported versions, missing tools and failed recoveries preserve the original member with notes. This feature does not add native decompilation.

Declarations, limits and tested variants

Dependencies and extras are displayed without resolving or fetching them. Compatibility tags are read from WHEEL, including multiple and compressed tags; filenames alone do not establish compatibility. RECORD and signature files are preserved, but RECORD hashes, signatures, package safety and installability are not verified.

Supported inputs are ZIP and ZIP64 wheels with one coherent top-level .dist-info distribution. Nested vendored metadata remains a resource. Tests cover pure-Python, namespace, stub-only, Linux, macOS universal and Windows wheels, plus .data resources, headers and scripts. Existing limits apply: five minutes per parent job, 1 GiB expanded data, 256 MiB per file, 25,000 entries and four nested layers. Optional bytecode attempts get up to 30 seconds each. Metadata reads are capped at 1 MiB per file, 256 metadata files, 4 MiB declared metadata and 2,048 headers per parsed file. Worker limits may stop processing sooner.

Malformed metadata, unsafe paths, collisions, corrupt files and limits are explained in DECOMPILATION-NOTES.txt; complete extracted siblings remain available. Encrypted and split ZIPs, EGG, source distributions, package editing, dependency installation and executable entry-point generation are outside this release.

For standalone bytecode, use the Python decompiler. For executable bundles or PYZ/zipapp archives, see PyInstaller; for Python packaged inside Android apps, see Kivy APK inspection.