Package URL (purl) Parser

Parse, build and normalise purl identifiers with the per-ecosystem rules applied, so the identifier you put in an SBOM actually resolves.

Runs locally

Everything happens in your browser. What you paste or drop here is never uploaded, logged or stored.

Package URLs, one per line

One identifier for a package, in any ecosystem

A Package URL (purl) names a software package the same way everywhere: pkg:type/namespace/name@version?qualifiers#subpath. It is how SBOMs, vulnerability databases such as OSV and GitHub's advisory database, and scanners agree they are talking about the same package. A malformed or non-canonical purl in an SBOM means that component is silently never matched against advisories.

The rules differ by ecosystem

The generic syntax is simple. The ecosystem rules are where purls go wrong, and this tool applies them from the official type definitions for 42 ecosystems. PyPI names are case-insensitive and treat _ as -, so Django_REST_framework becomes django-rest-framework. Maven requires a namespace (the groupId), and cargo forbids one. An npm scope keeps its @, percent-encoded as %40. A git purl uses the host as its namespace and keeps the repository path in the name. Parsed purls show both the canonical form and every note explaining what changed.

Percent-encoding, done once

Each component is decoded when parsed and re-encoded when built, with the character set the specification allows for that part. A qualifier value such as a repository URL has its slashes encoded, and a colon is left as it is. Parsing a canonical purl and building it again always produces the same string.

Tested against the specification

Our test suite runs the purl specification's own test data (586 parse, build and round-trip cases across every type), and 584 pass. The other two contradict another required case in the same suite about upper-case qualifier keys. This implementation lower-cases keys, as the Maven and round-trip cases require, and our test file names the two cases it cannot satisfy.

Frequently asked questions

What does "not a registered type" mean?

The purl parses, but its type is not one of the 42 in the specification. Other tools may not recognise it, so check whether an official type exists for that ecosystem.

Why was my npm package name not lower-cased?

npm names are case-sensitive in the purl specification: older packages with capital letters were allowed to keep them. Only ecosystems defined as case-insensitive are lower-cased.

Is anything looked up online?

No. Parsing and building use the specification's rules only; nothing checks whether the package exists.

References

Related tools

What this tool can and cannot tell you. It reports what is present in the input you provide. It cannot see anything you did not give it, and a clean result means nothing was found in that input - not that the wider system is secure.

Security guidance here follows current published sources - OWASP, MDN, the relevant RFCs, NIST, CISA, FIRST and MITRE - which are linked beside the specific claims they support.