Developer tools

requirements.txtParser and organizer

Read dependency declarations, inspect their fields, and export a reviewed group without rewriting the source.

requirements.txt

Dependency input

Selected dependency group

Text is processed in this browser. No package lookup, URL fetch or upload is performed.

Format and scope

For pyproject.toml: Only project.dependencies, project.optional-dependencies and build-system.requires are extracted. Other dependency tables are ignored.

100 KiB UTF-8 · 1000 dependencies · 4096 characters per declaration · markers are not evaluated.

Input or options changed. Parse again before exporting.

Use this requirements parser when a copied dependency list contains repeated declarations, extras or platform conditions. Seeing the name alone is not enough to decide whether two lines mean the same thing.

requirements.txt and pyproject.toml describe different parts of a project workflow. Here you can inspect their declared Python dependencies without creating an environment or running an installer.

Why inspect requirements.txt here?

Keep conditions and dependency groups visible.

Keep conditions attached

An environment marker belongs to its declaration. The result separates name, extras, specifiers, URL and marker into fields while retaining the original requirement. Nothing is removed because it appears irrelevant to this browser.

A declaration splits into separate fields while its condition remains attached

Remove repetition without guessing versions

Organize requirements.txt with a preview that counts exact duplicates and reordered entries. Two lines naming the same package with different constraints survive. In TOML, choose the runtime, optional or build group explicitly.

Two identical dependency cards become one while a different condition stays separate

Three checks before you take the result

01

Select the source format deliberately

Changing the format keeps your text in place. Use the example button to preview a replacement suited to the selected format; applying it provides one undo.

02

Check the source group

TOML starts at project.dependencies even when that group is empty. Optional extras and build-system.requires remain separate choices; selecting one does not activate or merge the others.

03

Watch freshness and preview counts

Auto parsing waits 350 ms. Turn it off to use the parse button or Ctrl/Cmd + Enter. A changed input or option disables export until a new result is ready.

Read declarations as structured data

Fields you can audit

The structured view includes original and normalized package names, extras, version specifiers, environment markers, direct references and source locations. Version spelling is checked, but no candidate version is tested against a range.

TOML with useful locations

A TOML 1.0 parser checks the whole document syntax. Supported dependency fields must contain string arrays. A malformed declaration points to its source string; unrelated tool tables are not checked against their own schemas.

One group, two export formats

JSON retains structured fields and the group name. TXT contains the selected declarations, one per line. The screen shows 50 records at a time; copy and download include the whole confirmed group.

What the result does and does not mean

A declaration list is not a lock file
No PyPI lookup, installation, transitive dependency resolution, conflict repair, vulnerability scan or license analysis is performed. A syntactically accepted declaration does not prove that an environment can be installed.
Only the supported pip subset
Use one named PEP 508 declaration per line. Blank lines and pip-style comments are ignored. File includes, constraints files, editable installs, index options, hashes, bare paths, continuations and environment-variable expansion are rejected.
Conditions stay as text
Markers are checked for syntax, including parentheses and and/or, but never evaluated. Standard variables and extra are supported; lock-file-only extras and dependency_groups variables are rejected. Direct references are opaque text and are never opened.
Standard pyproject fields only
Read project.dependencies, project.optional-dependencies and build-system.requires. Dynamic dependencies are rejected. Poetry tables and dependency-groups are not extracted. Extra group names must use lowercase letters, digits and single hyphens. This is not complete project metadata validation.
Organization changes the derived result
Sorting uses normalized package names, then the original declaration. Deduplication compares complete trimmed declarations within one group. Source comments and formatting stay in the input but are omitted from exports; a new parse resets organization.
Bounded, atomic processing
The input limit is 100 KiB in UTF-8, with at most 1000 dependencies and 4096 characters per declaration. Marker nesting is limited to 32 levels. Any supported-field error stops export for the whole document; no partial result is silently accepted.

requirements.txt questions

Can I add comments to a pip requirements file?

Yes. A line beginning with # is a comment, and whitespace followed by # starts an inline comment. This tool follows that rule; a URL fragment without preceding whitespace stays part of the URL. Comments remain in your input, but are not included in the extracted dependency list.

requirements.txt depending on python version

Yes. For example, importlib-metadata; python_version < "3.10" is conditional. The parser checks and preserves the marker. Your Python installer, not the browser, decides whether that declaration applies to the target environment.

Is requirements.txt still needed when using pyproject.toml?

It depends on the workflow. Standard project dependencies can live in pyproject.toml, while requirements.txt can be an installer input or an exported environment list. This tool extracts a selected standard group; it does not produce a resolved lock file or replace your build configuration.

Allowing different versions in requirements.txt?

You can use bounds such as package>=1,<2, or separate declarations with different markers. Different constraints are retained during deduplication. Multiple lines for the same name are not automatically alternatives and can still be incompatible.

How can I resolve a package version conflict?

Inspect the conflicting constraints in the target environment with your package manager. This tool can expose repeated declarations and show their conditions, but cannot compute a compatible version set. Removing an exact duplicate does not resolve contradictory constraints.

Unexpected version result?

Review the selected group

Return to requirements.txt with the group you want to inspect, then review the confirmed output before using it elsewhere.