User guide

No account needed. On the Demo page you can run a real sample in one click, or upload your own reads and validate them through the live pipeline, with no sign-in and no email. You get a private, bookmarkable link to your run, listing every sample with a link to its report.

No-login limits. By default a run without an account can hold up to 96 barcodes, 9,600 files and 5 GB of reads, and each internet address (for IPv6, each /64 network) can have one run at a time in progress. A whole flow cell of sup reads is often 11 to 13 GB, so upload only the barcodes you need. No-login uploads also pause while the server is short of storage.

Prefer an account? Registering is optional. It keeps a dashboard of your runs, keeps results and raw reads for longer, allows larger uploads, lets you reuse configurations, and restricts access to your own data.

No data handy? The Demo page has a downloadable example FASTQ and a pre-computed, interactive example report to explore.

Without an account, Upload & validate on the Demo page does all of this in one step: choose your folder or files, and every sample runs with the Default configuration and a size predicted from its reads. Your run's link lists each sample and opens its report when it is ready. To check a finished sample against its design, choose Compare to a design beside it and upload the design's FASTA or GenBank file. Expected sizes and your own configurations need an account, and follow the steps below.

1. Upload. On New run, choose your fastq_pass folder. Each barcodeNN sub-folder becomes one sample, and a flat folder of FASTQs is treated as a single barcode. A sample sheet is optional (columns: barcode, alias, approx_size, client, config) and simply names and routes your samples.
2. Configure. You then land on the configure screen. Give each sample an expected size of 500 to 500,000 bp (leave it blank to let the engine predict it) and a configuration, or use Apply to all to set them in one go. Note that leaving this screen discards the upload.
3. Submit. Click Submit to queue. Every sample is queued and processing begins, and you can follow progress live on the run page and the console.
4. Report. When a sample finishes, open its Report, or download the FASTA, GenBank or full export.

Open a live, interactive example report as you read this. It behaves exactly like the report a real run produces.

• QC verdict. PASS, WARN or FAIL, with every check shown as its value against the threshold, so you can see exactly why the verdict landed where it did. Section 4 explains each check.
• Plasmid map and features. The circular map alongside the annotation table from pLannotate.
• Base-support viewer. A Sanger-style, per-base view of how the reads support the consensus, with zoom and a marker that tracks onto the map.
• Sequencing summary. The reads behind the sample: how many passed the filter, their quality and length, the yield, the predicted size, and what they are made of. Plasmid purity is the share of plasmid-length reads the delivered sequence explains end to end; non-plasmid reads is the share of the reads checked that barely align to it, such as host DNA or debris, with the part that is E. coli given separately. Both are for information and don't change the verdict.
• Multiple sizes. If no expected size was given and the reads suggest several plasmid sizes, each is assembled and the strongest is shown, with the alternatives listed.
• Methods and provenance. The footer states how this sample was processed: the assembler, how many replicate assemblies agreed, the polishing model, where the published sequence starts, and the software versions when the run recorded them.

PASS means every check passed. WARN means the sequence was delivered but something deserves a look before you rely on it. FAIL means the result should not be used as it stands. Each check below appears in the report's QC checklist or as a banner. Without a design, a PASS says the sequence is what the reads support, not that it is the plasmid you designed: a clone whose reads all agree passes even if it differs from its design, so compare it with the design when you have one.

• Not a single plasmid (FAIL). More than 10% of the plasmid-length reads (reads at least 0.3 times the plasmid's length) come from a different molecule: reads the delivered sequence doesn't explain, which overlap each other as reads of one plasmid do. The sample holds more than one plasmid, for example a second clone or a contaminant. The report gives the share of reads that match. A second plasmid much smaller than the delivered one counts too: its whole reads, at least 1 kb long, are recognised because they overlap each other. With 25 to 49 plasmid-length reads the sample FAILs only when the share is clearly above 10%, and otherwise WARNs that a second plasmid is possible; with fewer than 25 the report says there are too few reads to check. When the other plasmid is another sample of the same run, the run page says which (see MIX below).
• MIX (label, not a verdict). Beside a sample's verdict on the run page. Once every sample of the run has finished, PlasValidate checks the reads each sample's plasmid doesn't explain against the other plasmids in the run. A sample is flagged when another sample's plasmid makes up 2% or more of its plasmid-length reads, from at least three reads and above the run's background level; a match shows that another sample holds the same plasmid, not where it came from. MIX is separate from the 10% FAIL rule: it can appear below that line, and a FAIL need not match any sample. The Cross-contamination card above the table lists each one, for example "barcode11 contains 2 other plasmids"; hover to see which. Plasmids too alike for the reads to tell apart are named together. With an account you can turn the check off on the run's configure screen.
• SAME (label, not a verdict). Beside a sample's verdict on the run page when another sample of the run delivered the same plasmid (differing at no more than 0.1% of its bases), for example replicate wells, or a sample that came out as its neighbour's plasmid. Hover for which sample and how many bases apart. The labels are cleared when you re-run, clear or remove a sample, and come back once every sample has finished.
• Mixed clone (FAIL). The reads split into two populations whose differences travel together on the same reads at three or more positions, so the consensus averages two closely related plasmids and is a faithful copy of neither. A position counts only if the other version is in at least 10% of the reads of each strand.
• Possible second version (WARN). Shown in the single-clone row. At a position where nanopore reads don't usually go wrong (not a homopolymer reading a few bases short or long, and not a single-base miscall or a one- or two-base slip at a Dam or Dcm methylation site), 20% to 50% of the reads carry a different base, miss a few bases or carry extra ones, and so do at least 10% of the reads of each strand. A change on one strand only is a basecalling error, common with hac models, not a second molecule. The sample may hold two versions of the plasmid that differ there, such as a mutagenesis clone and its parent. The report names each position and the share of reads.
• Most reads disagree (FAIL). Shown in the consensus agreement row. At a position where nanopore reads don't usually go wrong, more than half the reads carry a different base or lack bases the sequence has. The sequence should follow the reads, so it is likely wrong there. The report names each position and the share of reads.
• Structural variant (FAIL or WARN). At least 15% of the reads that span the site carry a deletion or insertion of 50 bp or more that the consensus does not include: a recombined or rearranged plasmid, or a second, shorter plasmid that shares the backbone. It FAILs when the reads make it clear (20% or more of them, at least 10 reads, each strand carrying at least a fifth of them) and WARNs otherwise.
• Tandem repeat (FAIL). The sequence is two or more copies of one shorter unit, differing by no more than 5 bases (or 0.1% of the unit), and the reads show molecules of the unit's size: a concatemer or self-ligation, not a real plasmid of the doubled size. The portal re-runs the sample at the unit size and shows that result.
• Two near-identical copies (FAIL or WARN). The sequence is two or more copies that differ by no more than 5 bases (or 0.1% of a copy), but the reads show whole molecules of the full length. When at least 5 reads run across the whole molecule and agree with it, the copies are real and the sample WARNs. Otherwise it FAILs: either the prep carries a two-copy form of the plasmid, or the assembly collapsed a long repeat and doubled it, and supplying the design as a reference tells the two apart. A plasmid designed with a long repeat whose copies differ by more is not flagged. These checks find a duplicated sequence; they do not count the units of a repeat array within the plasmid.
• Size conflict (WARN). The replicate assemblies did not settle on a length that matches the size the reads indicate (or the expected size, if you gave one), so the sequence's length is uncertain. The report gives the size the reads point to. If you didn't give an expected size, running again with it anchors the assembly to that size.
• Size checks. Size within expected (FAIL outside 0.8 to 1.5 times the expected size, unless a configuration sets another window) and Read length supports size (WARN when the size the read lengths show is more than 15% off the expected size, FAIL at more than 30%) apply only when you gave an expected size. Size matches read prediction is a WARN when the assembly and the size predicted from the reads differ by more than 30%.
• Not circularised (WARN). The pipeline could not confirm that the recovered sequence closes into a circle, for example because too few reads run from its end straight into its start.
• Reads reach target depth (WARN). The sample does not hold enough reads to draw the target depth for each replicate assembly. The report also shows the sample's own depth over all passing reads.
• Consensus depth (FAIL). Too few reads aligned to the read-anchored consensus to support it at the minimum consensus depth (60x unless a configuration sets another).
• Consensus agreement (FAIL). At more than 10% of positions, fewer than 70% of the reads agree with the consensus base (both thresholds can be changed in a configuration).
• Homopolymer length uncertain (WARN). In a run of 6 or more of the same base, the reads disagree about its length: another length has at least 0.7 times the reads of the length in the sequence. Nanopore reads often miscount long runs, especially reads basecalled with a hac model, so check these bases if they matter. Basecalling with sup gives fewer of them. Each one is listed in the report.
• Checks switched off (WARN). The configuration turned off the mixed-clone, structural or tandem-repeat check, so the sample was not tested for a second plasmid or a mixed clone, for a structural variant or circularity by the reads, or for a concatemer. The verdict says which checks were off.
• Too few reads to check (WARN). When too few reads aligned for the mixed-clone or structural check to judge, or too few span the positions that vary, the report says which check could not be made instead of passing it.
• Read diversity (WARN). The replicate assemblies reused largely the same reads, so they are less independent than they look.
• Genes annotated (WARN). A plasmid was assembled but pLannotate recognised none of its features. A synthetic or unusual backbone can do that while the sequence is right, so check it is the construct you expect. Not shown when annotation is switched off.
• Un-polished draft (FAIL). If the final Medaka polishing step fails, PlasValidate still delivers the read-anchored consensus, but the sample FAILs and the report names the cause. That draft can carry residual basecalling errors, so run the sample again once the cause is fixed. When the GPU ran out of memory because another job was using it, run again with the GPU free. A second polishing pass that fails while a polished sequence is still delivered (the second model for hac reads, or a re-polish) is a WARN.
• Default polishing model (WARN). The reads' headers don't name the basecaller model, so Medaka polished with its default R10.4.1 bacterial model. Check that it suits your chemistry; the flag says nothing about the plasmid itself.
• Damaged read files (WARN). A truncated or corrupt FASTQ was read up to the damage. The report names each file and how many complete reads were kept from it.
• Comparison to a reference (FAIL for any difference). Choose Compare to a design for a finished sample (Validate on the run page with an account), and upload the design. With a design sequence supplied, any difference between it and the delivered plasmid FAILs the sample, and the report lists each one: its position on the plasmid, the change, the share of reads carrying each version, the feature it falls in (and, in a gene, whether an insertion or deletion shifts the frame or what a substitution does to the protein, such as missense Leu3Pro; not for a partial copy of a gene, whose frame isn't known), and what the reads suggest. Nearly every read agreeing means the clone really carries the change; a real share carrying the design's version means the sample may hold both; a change in a homopolymer run or a methylation site, where nanopore reads go wrong on their own, is marked as such. An assembly that does not cover the whole reference FAILs, and so does a reference of half the plasmid or more that leaves part of the plasmid out (it may be a partial design, or the clone may carry extra sequence; the report says how much it covers). A reference much shorter than the plasmid, such as an insert on its own, is checked as a region: the report says how much of the plasmid it covers and the identity within it (WARN, since the rest was not checked).

• Raw reads are kept for 7 days after a run finishes with an account, or 24 hours without one (compressed once it completes), so you can re-run a sample in place, either by requeuing it or by changing its size or configuration and confirming the re-run, without uploading again. After that the raw reads are removed, so a later re-run means uploading once more.
• Results are kept for 30 days after a run finishes with an account, or 7 days without one, after which the run and its deliverables are removed automatically. Download anything you want to keep before then. An upload that is never submitted is removed within 12 hours.
• Each run has an upload limit: by default 20 GB and 20,000 files with an account, and 5 GB and 9,600 files without one. A gzipped file may expand to at most about 20 times its size (nanopore FASTQ compresses about 3 to 1), so a FASTQ with the same quality character throughout, made from a FASTA, may need to be uploaded uncompressed. A read longer than 1,000,000 bases is skipped; no plasmid read is that long. Uploads pause automatically if the server is running low on space.
• Each sample may run for up to 4 hours. One that reaches the limit is stopped and reported as failed, with the cause. Large tandem-repeat plasmids come closest (see Limits).
• Annotations are also kept in an annotation cache, so a plasmid that has been annotated before is not annotated again (6 to 9 seconds saved a sample). An entry holds the annotated sequence and goes once it has gone unused for 30 days; deleting a run does not remove it. The cache is shared by everyone on this server. The same sequence always gives the same annotation, so nothing about your plasmid is passed to anyone else, but a sample that annotates unusually quickly shows that someone here has annotated that exact sequence before.
• The privacy statement sets out what is stored and who can see it.

A configuration bundles the pipeline and QC settings you want to reuse. Everyone gets the built-in Default (read-only); create your own under Configs to tune assembly (including the primary and fallback assemblers and methylation-aware polishing), the QC thresholds, or which report sections to include, then assign it to samples on the configure screen.

The figures on the front page come from one benchmark, run the same way for both tools.

• Data. Oxford Nanopore's public plasmid_2025.04 release: 96 designs, each sequenced on four flow cells (384 samples), each with its published design, basecalled with the sup model.
• Exact. A sequence counts only if it is identical to the design: same length, no substitutions, no insertions or deletions, compared around the circle so rotation and strand don't matter. No design or expected size was given to PlasValidate; the designs were used only afterwards, to score the sequences.
• Scored on 376. Two designs, barcodes 02 and 19, are left out on all four flow cells (8 samples): 99.7% and 97% of their reads carry a difference from the published design at one position (barcode19's is a homopolymer one base shorter), so no tool can reproduce the design from these reads, and neither tool does. We did not make or sequence these clones, so we cannot say whether the clone or the published design is wrong. Everything else counts, including the mixed prep below.
• PlasValidate 1.0, given only the reads: 372 of 376 exact (372 of all 384). All four flow cells took 20.8 minutes and 3.4 CPU-hours (three timed runs within 5 seconds of each other, with byte-identical output), about 16 times faster than EPI2ME with a fifth of its CPU time. Given each clone's expected size it delivers the same sequences.
• EPI2ME wf-clone-validation v1.8.4, in Oxford Nanopore's published configuration (Canu) and given every clone's expected size: 348 of 376 exact when we reran it, 345 in Oxford Nanopore's own published results. It took 5.6 hours and 16.7 CPU-hours.
• Same machine. Both ran on the same workstation with the same 12 CPU threads and nothing else running. Wall time differs more than CPU time because the two tools use the CPUs differently. PlasValidate's polishing used the machine's GPU, which EPI2ME's does not, and CPU-hours leave GPU time out; on 3 hac samples, Medaka on the CPU gave the same sequence in about the same time (8-11 s each). In the timed runs each sample's annotation was copied from a cache filled by earlier runs of the same sequences; annotating afresh adds about 6 to 9 seconds a sample.
• The 4 that differ from the design are barcode51 on all four flow cells: a mixture in which about 70% of the reads carry a one-base variant and 30% the design. PlasValidate delivers the majority version and warns that the sample holds both, naming the position; EPI2ME's sequence is byte-identical to PlasValidate's. Among the 376 scored samples, no sequence that differed from the design received a PASS, on sup or hac reads.
• hac basecalls of the same run: 353 of 376 exact in 20.7 minutes, against 332 in Oxford Nanopore's published EPI2ME results for them (27 samples only PlasValidate gets exact, 6 only EPI2ME). Speed was compared on sup reads.

The scripts that reproduce this are in the source code (scripts/benchmark). EPI2ME and Oxford Nanopore Technologies are trademarks of Oxford Nanopore Technologies plc; PlasValidate is not affiliated with it.

• Tested on Oxford Nanopore R10.4.1 reads of plasmids grown in E. coli. R9.4.1 reads and plasmids grown in other hosts are untested.
• One benchmark. The checks and their thresholds were set on Oxford Nanopore's public benchmark, four flow cells of the same 96 clones, so its samples are replicates, not independent clones. The only data from another laboratory are eight repeat-rich plasmids.
• Minorities have a floor. A minority below about 15-30% of the molecules, depending on the problem, can pass. Measured on mixtures of real sup and hac reads of three plasmids of 2.7 to 7.2 kb at 100x to 2,000x (15 runs per setting, 5 for the plasmid sharing the backbone), the floors are: an unrelated second plasmid 15-20%, a second plasmid sharing the backbone 15-30%, a one-base second version 22-30%, a 10 bp deletion 30% (50% on sup at 100x), a mixed clone 22-25%, a 500 bp deletion 25-40% and a 1.3 kb insertion 20%. A second version near 20% of the reads sits on the line: one benchmark sample carries another's 10 bp deletion in 16-20% of its reads and passes.
• Small plasmids. On plasmids under about 4 kb, a deletion of about 0.6 to 1.3 kb or an insertion of about 0.8 kb carried by a minority of the molecules can be missed.
• Homopolymers in hac reads. Their lengths are flagged, not corrected, and a one-base error in a homopolymer is not always flagged. sup basecalls give the most exact sequences.
• Repeat copy number can be missed when few reads span the whole repeat. On a repeat-rich 11.9 kb plasmid from another laboratory, only 3 reads ran across the whole plasmid, and PlasValidate delivered one 240 bp repeat unit more than the design without a check pointing to it. The same reads always give the same sequence and verdict.
• Large tandem-repeat plasmids are slow: a 22 kb one took 93 minutes on 4 CPU threads and 3 h 14 min on one, close to the 4-hour limit per sample.
• Below 60x consensus depth every sample FAILs, even one that matches its design, and a second plasmid seen in fewer than 25 plasmid-length reads is not failed.
• Without a design, a clone whose reads all agree passes even if it differs from its design. Only comparing it with the design shows the difference.
• Mixtures are failed, not separated: you get the majority plasmid and the reason. The cross-check only knows the plasmids of the same run, and a match names another sample, not where the plasmid came from.

Questions, feedback, or a plasmid that did not validate as you expected? Get in touch at contact@plasvalidate.com, or use the contact page.