Python

Requirements.txt Parser

Breaks a requirements file into packages, extras, specifiers and markers, and flags the loose ones.

Loading the tool…

Processing happens locally in your browser. What you paste or load is processed by this page and is not uploaded to a server. Nothing is stored unless you use a control that says it stores something, and you can clear anything this site has kept from the privacy page.

How to use this tool

  1. Paste the requirements file, or load it with the picker.
  2. Select Parse the requirements.
  3. Read the last column for what each specifier actually commits you to.
  4. Download the CSV if you want the list in a review or a ticket.

What requirements.txt parser does

A requirements file is a small language pretending to be a list. A single line can carry a package name, a set of extras in square brackets, several version constraints, and an environment marker after a semicolon — and lines beginning with a dash are not packages at all but options that change how pip behaves for everything after them. This page pulls each line apart and shows what it actually says.

The column that earns its place is the last one. A pinned package is reproducible but will not pick up a security fix on its own. A package with no version at all is the line that breaks a build months later, when a new release lands and nobody changed anything. A constraint with a lower bound and no upper bound will happily install a future major version. None of those is wrong in every project, but knowing which of your lines is which takes about ten seconds here and a surprisingly long time by eye.

Frequently asked questions

It depends on the project, which is why the page describes rather than scolds. A line with no version at all is the one that breaks a build months later when a new release lands and nobody changed anything. A constraint with a lower bound and no upper bound will install a future major version without asking. An exact pin is reproducible but will not pick up a security fix on its own. An application usually wants pins; a library usually wants ranges.

They are pip options rather than packages, and they are shown with an explanation of what each does. Some matter more than they look: -r pulls in another file whose contents are not visible here, -c applies constraints without installing anything, and --extra-index-url adds a second package index, which is worth reviewing because a name published to both indexes is resolved in a way you cannot rely on.

Everything after a semicolon on the line is an environment marker — a condition deciding whether the requirement applies at all, such as python_version >= "3.9" or sys_platform == "win32". It is shown separately from the version specifier because the two are read together: a package can be pinned tightly and still not be installed at all on the machine you are debugging.