How does the converter translate version specifiers between formats?

**Poetry** uses two non-standard operators that need translation: - **^1.2.3** (Poetry caret, "compatible up to next major") -> **>=1.2.3, **~=1.2.3** in PEP 621 - **1.2.3** with no operator (Poetry exact match) -> **==1.2.3** in PEP 621 - **>=1.2, Poetry), the converter turns **==1.2.3** back into bare **1.2.3** and **~=1.2.3** back into **~1.2.3** where the conversion is unambiguous. **Ranges with explicit operators** (`>=1.2,<2.0`) are kept verbatim because they mean the same thing everywhere.

Does it preserve VCS URLs (git+https://...) and editable installs (-e .)?

**Yes.** A line like `-e git+https://github.com/user/repo.git@main#egg=mypkg` in requirements.txt becomes: - **Poetry**: `mypkg = { git = "https://github.com/user/repo.git", branch = "main", develop = true }` - **PEP 621**: `"mypkg @ git+https://github.com/user/repo.git@main"` in the dependencies array, with `develop` handled by the tool config - **Pipfile**: `mypkg = { git = "https://github.com/user/repo.git", editable = true }` **Editable local installs** (`-e .`) work the same way. **The converter does not try to "resolve" the URL**, it just rewrites the syntax. You still need to run `pip install` / `poetry install` / `pipenv install` once to fetch the package.

What happens to environment markers like ; python_version >= "3.11"?

They are **kept verbatim** and re-attached to the same dependency in the output format. A line like: ``` requests==2.31.0 ; python_version >= "3.11" ``` becomes: - **Poetry**: `requests = { version = "2.31.0", markers = "python_version >= \"3.11\"" }` - **Pipfile**: `requests = { version = "==2.31.0", markers = "python_version >= \"3.11\"" }` - **PEP 621**: kept inline in the dependencies array, exactly as written The converter **does not validate the marker syntax**: if you wrote something Python's packaging library does not understand, the converter still passes it through and the install step will tell you.

How do I know which dependencies are "dev" if my file does not say so?

The converter uses three signals, in order: - **Explicit groups** in the source format: **[tool.poetry.group.dev.dependencies]** (Poetry), **[dependency-groups].dev** or **[project.optional-dependencies].dev** (PEP 621), **[dev-packages]** (Pipfile) - **Section comments** in requirements.txt: a line like **# dev**, **# === testing ===** or **# development** flips subsequent dependencies into the dev group until another section comment ends it - **Trailing inline comments** in requirements.txt: `pytest==8.0.0 # dev` puts that single line into the dev group If your requirements.txt has no markers, **everything lands in the main group** (production deps). You can toggle **Group dev deps separately** off to flatten everything into one section regardless.

My Poetry file has python = "^3.11". What happens when I convert to PEP 621?

It becomes **requires-python = ">=3.11"**. The Poetry caret `^3.11` technically means "**>=3.11, =3.11"` is the standard idiom (you almost never need to cap the Python major version, Python 4 is not coming any time soon). If you convert back the other way, **>=3.11** becomes **^3.11**, which is the closest Poetry equivalent.

Does it support poetry 2.0 / the new PEP 621 mode in Poetry?

**Yes, via the PEP 621 output**. Poetry 2.x can now read **[project]** tables natively. If your team is on Poetry 2.x and you want the standard format, **convert to pyproject.toml with style = PEP 621**: the result works in Poetry 2, **uv**, **PDM**, **Hatch** and **setuptools** alike. The legacy **[tool.poetry]** style is still supported by the converter for older Poetry projects (1.x).

Can I convert a Pipfile.lock or poetry.lock too?

**No, and you should not want to.** **Lockfiles** (Pipfile.lock, poetry.lock, uv.lock) are not source files: they are **frozen snapshots** of the exact versions, hashes and dependency graph the resolver produced, often with hundreds of transitive entries. **You do not edit a lockfile by hand**. You edit the **source file** (Pipfile / pyproject.toml / requirements.txt) and let the package manager regenerate the lockfile. **If you want a frozen pinned requirements.txt** from a lockfile, use `pip freeze`, `poetry export` or `uv pip compile` instead.

What if my requirements.txt has -r other-file.txt or --index-url?

These are **pip command-line flags**, not real dependencies, so the converter **cannot turn them into a Poetry or Pipfile equivalent**. They are kept as **comments** in the output (e.g. `# pip-flag: -r dev-requirements.txt`) so you do not lose them, but you have to **handle them manually**: a private **--index-url** becomes `[[tool.poetry.source]]` in Poetry or `[[source]]` in Pipfile, and a **-r** include should usually be flattened by hand or solved with **dependency groups** in the target format.

Is anything sent to a server?

**No.** The entire converter runs **in your browser**. Your dependencies, your private package names, your git URLs, your version pins, nothing is uploaded. **There is no API, no analytics on your input, no logs.** If you want to verify it, open DevTools, switch to the Network tab, paste a sample, and you will see zero outbound requests. You can also clone the page and serve it from `file:///`: it works the same way offline.

Python Deps Converter - free

[tool.poetry] name = "myproject" version = "0.1.0" [tool.poetry.dependencies] python = "^3.11" requests = "2.31.0" django = ">=4.2,<5.0" pandas = "~2.1.0" [tool.poetry.group.dev.dependencies] black = "24.3.0" # dev pytest = "8.0.0" # dev

Move a Python project between requirements.txt, pyproject.toml and Pipfile

You inherited a project that uses requirements.txt but the rest of your team is on Poetry. Or you want to try uv, which expects PEP 621 style pyproject.toml. Or you finally want to drop Pipenv and ship a real lockfile. The annoying part is never the package manager: it is the 30 dependencies you have to rewrite by hand without breaking a version pin.

This tool converts dependency files between formats: requirements.txt, pyproject.toml (both Poetry and PEP 621 style used by uv, PDM and Hatch) and Pipfile. You paste one side, you get the other. Live conversion, no upload, nothing leaves your browser.

The parser understands version specifiers in each ecosystem, ^1.2.3 (Poetry caret) becomes >=1.2.3,<2.0.0 in PEP 621, ~=1.2.3 stays a tilde, ==1.2.3 stays pinned. Dev dependencies stay separated, inline comments (`# dev`, `# pinned for compat`) round-trip, VCS URLs (`git+https://...`), editable installs (`-e .`) and environment markers (`; python_version >= "3.11"`) are preserved.

How to use it

Pick the input format in the top-left bar: requirements.txt, pyproject.toml or Pipfile. Paste your file into the left textarea, the converter starts running immediately.
Pick the output format on the right. You cannot pick the same format on both sides, the matching button is grayed out.
If you are exporting to pyproject.toml, choose the style: Poetry (used by Poetry itself) or PEP 621 (used by uv, PDM, Hatch, setuptools). The two are structured differently and your tooling will reject the wrong one.
Toggle Group dev deps separately to keep development packages (linters, test runners) in their own section. The parser recognizes # dev comments in requirements, [tool.poetry.group.dev.dependencies] in Poetry, [dependency-groups].dev in PEP 621, and [dev-packages] in Pipfile.
Toggle Preserve comments to keep your inline notes (`# pinned, see CVE-2024-...`) attached to the right dependency.
Toggle Sort alphabetically if your team uses sorted dependency files. Off by default so your original ordering survives.
Copy the result, or Download it as the right filename (`requirements.txt`, `pyproject.toml`, `Pipfile`).
Swap direction flips the two sides and feeds the current output back as input, useful for sanity-checking a round trip.

When this is useful

Six situations where pasting and clicking beats rewriting by hand:

Moving an old project to Poetry. You have a 40-line requirements.txt with two # dev sections. You paste it, switch to Poetry pyproject, the dev group lands in [tool.poetry.group.dev.dependencies] automatically.
Trying uv on an existing Poetry project. uv is PEP 621 native and 10x faster than Poetry. You paste your Poetry pyproject.toml, switch the output to PEP 621, you get the format uv expects (`[project]` + `dependency-groups`).
Leaving Pipenv behind. Pipfile is dying. You convert your Pipfile to pyproject.toml in two clicks. The python_version from [requires] lands in requires-python.
CI pipelines that need requirements.txt. Your project uses Poetry, but your Docker image installs from a plain requirements.txt for caching. You paste the Poetry file, get requirements.txt with the same pins, drop it in.
Auditing a versioning mess. Someone wrote ^, ~, >= and bare pins in the same file. Convert to requirements.txt to see all the version constraints in the canonical PEP 440 form side by side.
Onboarding a new dev. The new person uses uv, the project uses Poetry. You paste the Poetry file, send them the PEP 621 output, they are unblocked in 60 seconds.

Questions and answers

Poetry pyproject.toml uses [tool.poetry] and [tool.poetry.dependencies] with Poetry-specific syntax (`name = "^1.2.3"`, caret means "up to next major"). PEP 621 pyproject.toml is the standard format defined by Python itself: it uses [project] with dependencies = ["name>=1.2.3"] as a list of PEP 440 strings, the same format requirements.txt uses. uv, PDM, Hatch and setuptools all use PEP 621. Poetry is moving toward supporting both, but its default is still the legacy table format. If your tool says "could not find [project] table", you have the wrong style: switch the converter to PEP 621.

Move a Python project between requirements.txt, pyproject.toml and Pipfile

How to use it

Pick the input format in the top-left bar: requirements.txt, pyproject.toml or Pipfile. Paste your file into the left textarea, the converter starts running immediately.

Pick the output format on the right. You cannot pick the same format on both sides, the matching button is grayed out.

If you are exporting to pyproject.toml, choose the style: Poetry (used by Poetry itself) or PEP 621 (used by uv, PDM, Hatch, setuptools). The two are structured differently and your tooling will reject the wrong one.

Toggle Group dev deps separately to keep development packages (linters, test runners) in their own section. The parser recognizes # dev comments in requirements, [tool.poetry.group.dev.dependencies] in Poetry, [dependency-groups].dev in PEP 621, and [dev-packages] in Pipfile.

Toggle Preserve comments to keep your inline notes (`# pinned, see CVE-2024-...`) attached to the right dependency.

Toggle Sort alphabetically if your team uses sorted dependency files. Off by default so your original ordering survives.

Copy the result, or Download it as the right filename (`requirements.txt`, `pyproject.toml`, `Pipfile`).

Swap direction flips the two sides and feeds the current output back as input, useful for sanity-checking a round trip.

When this is useful

Six situations where pasting and clicking beats rewriting by hand:

Moving an old project to Poetry. You have a 40-line requirements.txt with two # dev sections. You paste it, switch to Poetry pyproject, the dev group lands in [tool.poetry.group.dev.dependencies] automatically.
Trying uv on an existing Poetry project. uv is PEP 621 native and 10x faster than Poetry. You paste your Poetry pyproject.toml, switch the output to PEP 621, you get the format uv expects (`[project]` + `dependency-groups`).
Leaving Pipenv behind. Pipfile is dying. You convert your Pipfile to pyproject.toml in two clicks. The python_version from [requires] lands in requires-python.
CI pipelines that need requirements.txt. Your project uses Poetry, but your Docker image installs from a plain requirements.txt for caching. You paste the Poetry file, get requirements.txt with the same pins, drop it in.
Auditing a versioning mess. Someone wrote ^, ~, >= and bare pins in the same file. Convert to requirements.txt to see all the version constraints in the canonical PEP 440 form side by side.
Onboarding a new dev. The new person uses uv, the project uses Poetry. You paste the Poetry file, send them the PEP 621 output, they are unblocked in 60 seconds.

Questions and answers

Python Deps Converter

Move a Python project between requirements.txt, pyproject.toml and Pipfile

How to use it

When this is useful

Questions and answers

Related tools

JSON / YAML / TOML converter

npm / yarn / pnpm / bun translator

package.json validator

Python Deps Converter

Move a Python project between requirements.txt, pyproject.toml and Pipfile

How to use it

When this is useful

Questions and answers

Related tools

JSON / YAML / TOML converter

npm / yarn / pnpm / bun translator

package.json validator