Package Version Format Translator
Paste one or more version strings (one per line) and see which ones are valid SemVer, valid PEP 440, both, or neither — and exactly why a version that looks fine in one ecosystem can be rejected, or silently mean something different, in the other.
Processed locally in your browser. Your file is never uploaded.
How to use this calculator
- Paste a version string, or several — one per line — nothing leaves your browser.
- Select "Check versions".
- Review each flagged value: which grammar it fails (or which subtle semantic difference applies), and why.
- Use the suggested rewrite where one is offered — some translations are only approximations, and those are explained rather than silently applied.
Assumptions
- Recognises the common forms of two grammars: SemVer 2.0.0 ("MAJOR.MINOR.PATCH[-prerelease][+build]") and PEP 440 ("[N!]N(.N)*[{a|b|rc}N][.postN][.devN][+local]"). Unusual or vendor-specific version schemes (Debian's epoch/revision suffixes, Maven's qualifiers) are out of scope.
- Comparison/ordering semantics between two version numbers are not implemented — only correct parsing, validity checking, and safe round-tripping.
- A rewrite is only ever offered when it is unambiguous and lossless — stripping a git-tag "v" prefix, or padding a 2-component release to three. A PEP 440 dev/post suffix has no exact SemVer equivalent, so no automatic rewrite is applied for it, even though an approximate mapping is described.
Methodology
Each line is parsed against both grammars using hand-rolled, spec-derived regular expressions (SemVer 2.0.0's own official grammar regex, and a PEP 440 pattern covering epoch/release/pre-release/post/dev/local segments). The result is then checked against the specific, well-documented ways the two ecosystems disagree: a hyphen SemVer requires before a pre-release that PEP 440 doesn't, dev/post releases PEP 440 has and SemVer has no equivalent for, build-metadata semantics that differ (SemVer ignores it for precedence, PEP 440's local version does not), a git-tag "v" prefix neither grammar expects, a leading zero that's invalid in strict SemVer, and a 2-component release that PEP 440 allows but SemVer doesn't.
Worked example
A Python-style pre-release without SemVer's required hyphen
Inputs: 1.0.0a1
Result: Valid PEP 440 (alpha 1), but strict SemVer requires a hyphen before any pre-release identifier and will reject this outright. Flagged as an error with the SemVer-correct rewrite "1.0.0-a1".
Build metadata vs. PEP 440's local version
Inputs: 1.2.3+build1
Result: Valid under both grammars as text, but SemVer requires the "+build1" part to be ignored for precedence (so "1.2.3+build1" == "1.2.3+build2"), while PEP 440's equivalent local-version segment does affect ordering. Flagged as a warning explaining the semantic difference; no rewrite is offered because the ambiguity is in the specifications, not the string.
A PEP 440 dev-release suffix
Inputs: 1.0.0.dev0
Result: Valid PEP 440 (a development release before 1.0.0), but SemVer has no directly equivalent concept. Flagged as an error explaining that an approximate SemVer spelling like "1.0.0-dev.0" is sometimes used, while being explicit that it's an approximation with different precedence rules — not offered as an automatic rewrite.
Practical guidance
- If a package needs to publish under both an npm-style (SemVer) and a PyPI-style (PEP 440) identity, pick a version scheme that satisfies the stricter of the two grammars — a plain "MAJOR.MINOR.PATCH" with a hyphenated pre-release ("1.2.3-rc1") is valid and means the same thing under both.
- Never rely on build-metadata or PEP 440 local-version ordering for anything that matters — treat that part of a version string as informational-only, since the two ecosystems don't agree on whether it affects precedence.
- Strip a git-tag "v" prefix before feeding a version into any parser or comparison library — it's free to remove and neither grammar expects it.
Common mistakes
- Assuming "1.0.0a1" and "1.0.0-a1" mean the same thing to every tool — the first is only valid PEP 440, the second is valid under both, and a strict SemVer parser will simply reject the first rather than reading it leniently.
- Treating a PEP 440 dev/post suffix as something with an exact SemVer translation — there isn't one; any mapping is an approximation with different comparison behavior.
FAQs
Why is "1.0.0a1" flagged as an error instead of just a warning?
Because it's not merely non-idiomatic — a strict SemVer parser will fail to parse it at all, the same way a JSON parser fails on a trailing comma. That's a hard incompatibility, not a style preference.
Why doesn't the tool just rewrite "1.0.0.dev0" to a SemVer equivalent automatically?
Because there isn't a guaranteed-equivalent one. PEP 440's dev/post releases model "before" and "after" a release in a way SemVer's pre-release/build fields don't capture the same way, so any SemVer spelling is an approximation with different ordering behavior — this tool only auto-rewrites when the result is genuinely lossless.
Is "1.2.3+build1" actually broken?
Not broken as text — it's valid under both grammars. The risk is purely in how a build/local-version suffix affects version comparison, which differs between the two ecosystems' own tooling.