Plasmid Identifier — Match an Unknown Plasmid to a Known Backbone

Thirty curated backbones, and the full list with accessions is shown under every result: the classic cloning vectors (pUC19, pUC18, pUC118, pBR322, pACYC184, pACYC177, pBluescript II SK(+) and KS(+), pGEM-3Z, pSC101, pWSK29, pKK223-3), the pRS yeast shuttle and integrating series plus YEp13, the pKD recombineering templates and pKD46, pEGFP-N1 and pEGFP-C1, pET-3a, the plant binary vector pBI121, and the BAC vectors pCC1BAC and pBACe3.6. It is a screen against that set — not a search of Addgene's roughly 100,000 deposited plasmids or PlasmidScope's 850,000-plus, and it will not recognise a lentiviral, AAV, Gateway or bespoke synthetic backbone that is not in it.

Almost certainly not — a no-match is a statement about the thirty-vector reference set, not about your sequence. A reference has to share at least 5% of your query's 20-mers before it is aligned at all, so a backbone outside the set simply produces an empty table. That is also why the page lists every reference it screened against underneath the result: so a blank answer reads as the limit of the search rather than a verdict on your plasmid.

Because they fail differently, and one averaged number would hide which happened. Identity is computed only over alignment columns where a query base sits opposite a reference base; coverage is how much of your query those columns account for. High identity over low coverage is that backbone carrying something extra — your insert — while lower identity over near-full coverage is a derivative of the backbone with changes throughout. The example on the page shows the first case: pUC19 at 100% identity over 87% coverage, the missing 13% being the GFP fragment. Candidates are ranked on identity multiplied by coverage, so a slightly imperfect match spanning your whole sequence can outrank a perfect match to part of it: on that same example pUC118 (88.25% identity, 99.97% coverage) sits above pUC19, and pUC19 is still the honest answer. Read both columns rather than taking row one as the verdict.

One hard check only: whether the query switches between two different known backbones. That is the check that can fail the gate. The second check — top match at 95% identity or better over 90% coverage or more — is marked soft and never flips the verdict, because how confidently a plasmid is identified is not a pass/fail question. The badge also carries the screen's own "not checked" list, which includes point mutations relative to the specific reference accession, and any judgement about what an unmatched region actually is.

Read the switch points before deciding. Several references in the set are near-identical over long stretches — pUC19, pUC18 and pUC118 share most of their length — so a switch between two of those is usually just whichever reference scored marginally higher across one window and means nothing. A switch between distantly related backbones is more interesting. Positions are resolved to the 100 bp step of the scanning window, so treat them as approximate.

Yes, but read the coverage column knowing that. A partial read explains less of the reference and less of itself, so coverage drops and an ordinary vector can look like a mediocre match; whatever you did not sequence also cannot be identified and will appear as an unidentified region. For a linear fragment untick "Circular molecule": that setting decides whether a window near either end of the sequence wraps around the origin rather than being cut short, and whether the last stretch of the sequence is compared against the first one for a backbone switch across the join.

Three different questions. The Plasmid Annotator labels the parts — promoters, tags, origins, resistance markers — of a plasmid you already know. This page answers which catalog vector the whole molecule is, and nothing else: ranked backbones, coverage, chimera switch points. Identify Plasmid combines the two, crossing this backbone screen with feature annotation to report the regions that neither explains. Use this one when the backbone identity is the whole question, and that one when you want the insert triaged too.

No. The sequence is used only to run the screen and is never logged or stored, and the reference set is read from files on SeqBench's own server rather than queried from any third party. The same call, gate included, is available as plasmid_identify on the REST API and the MCP server, which is how you would triage a freezer box of unlabelled sequences rather than one tube at a time.