How to Open a .dna File Without SnapGene
8 min read · Updated August 5, 2026
Someone sends you a plasmid as a file called something like pET28a-insert.dna. You double-click it and your computer either does nothing or offers to open it in a text editor, which produces a screen of garbage. Nothing you already have installed reads it, and the sequence you actually need is sitting right there inside the file.
This is a solvable problem, and you do not have to install anything to solve it. Here is what the format is, why the obvious workarounds fail, and the four routes to getting the sequence and its annotations out.
What a .dna file actually is
A .dna file is SnapGene's own native format. It is not text, and it is not a renamed GenBank or FASTA file — it is a binary container, and its layout has never been publicly specified by SnapGene. Everything that reads it outside of SnapGene itself does so through reverse engineering, principally the work behind Edinburgh Genome Foundry's snapgene-reader and Biopython's own SnapGene parser.
The structure that community work uncovered is a simple sequence of length-prefixed segments: one byte identifying the segment type, four bytes giving that segment's length as a big-endian integer, then that many bytes of payload. A valid file opens with a cookie segment whose payload begins with the ASCII text "SnapGene". After that come the segments that matter to you — the DNA sequence itself (with a flags byte where the lowest bit records whether the molecule is circular), the feature annotations, and the saved primers.
The useful quirk is that the features and primers are stored as XML, in plain text, inside a binary wrapper. That is why opening a .dna in a text editor is not completely useless: among the garbage you will often see recognisable feature names like "AmpR" or "T7 promoter" and, if you scroll, a long readable run of ACGT. It is also why that approach is not a real answer — you cannot reliably tell where the sequence starts and stops, whether it is circular, or which coordinates each feature occupies.
Why renaming the file does not work
The most common first attempt is to rename pET28a-insert.dna to pET28a-insert.txt, .gb, or .fasta and hope something opens it. This never works, and it is worth understanding why so you stop trying.
A file extension is a hint to your operating system about which application to launch. It carries no information about the bytes inside the file and changing it changes nothing about them. A GenBank parser fed a .dna file will look for a line starting with LOCUS, find binary noise, and fail. A FASTA parser will look for a line starting with ">" and fail the same way. The bytes are the problem, not the name.
Copy-pasting the ACGT run you can see in a text editor is a slightly better hack, and it will sometimes get you a usable sequence. It also silently discards every annotation, loses the circular/linear topology, and gives you no way to check that you captured the full sequence and nothing else. If the file was worth sending to you, the annotations were probably the point.
Four ways to actually read it
Ranked roughly by how quickly they get you to an answer:
- SeqBench's SeqStudio, in the browser. Import the .dna directly — no install, no account. You get the sequence, the features on a circular or linear map, and a live restriction-site scan, and you can edit and export from there. This is the fastest route if you just need to see and use the construct.
- SnapGene itself, in free Viewer mode. SnapGene and the old separate SnapGene Viewer are now one application: you download SnapGene, and without a licence it runs in a free mode that lets you view, annotate and share sequence files. Editing, aligning and cloning are the licensed features. This is the most faithful reader of the format, since it is the format's owner, at the cost of a desktop install.
- Biopython, if you are already scripting. Bio.SeqIO.parse(handle, "snapgene") has read .dna files since Biopython 1.75, giving you a SeqRecord with the features populated. Note the asymmetry: Biopython reads this format but cannot write it, so it is a one-way door.
- Ask the sender to export GenBank instead. Underrated, and the correct long-term fix — see the last section. Not helpful when the sender is a former lab member who graduated two years ago.
Converting .dna to GenBank, and GenBank back to .dna
GenBank flat file (.gb / .gbk) is the interchange format you actually want. It is plain text, it is openly specified, every tool reads it, and it carries the same things you care about from a .dna: the sequence, the topology, and a FEATURES table with labels, types, coordinates and strands.
Going .dna → GenBank is well served: SnapGene exports it, Biopython can read a .dna and write GenBank, and SeqStudio does the conversion by importing one and exporting the other. Going the other direction is the part that is usually missing. Biopython explicitly has no .dna writer. Most free viewers stop at reading. So if a collaborator works in SnapGene and needs your edits back in their own format, the usual answer is "send them GenBank and let them import it".
SeqStudio writes .dna as well as reading it, which makes a genuine round trip possible: open the colleague's .dna, make your edits, and hand back a .dna they can open natively. If you only need one direction and you are working with plain text formats, the Format Converter handles FASTA, GenBank and TSV interconversion and can pull out CDS features as nucleotide or protein FASTA.
What survives the round trip and what does not
Any reader built on reverse engineering handles the segments someone bothered to decode and skips the rest. In practice that means the parts of the file you are almost certainly after come through intact, and the parts specific to working inside SnapGene do not.
- Comes through: the full sequence, whether the molecule is circular or linear, and the feature annotations with their labels, types, coordinates and strand. Saved primers are also stored as XML and are commonly recovered.
- Usually dropped: saved alignments, the edit/history log, free-text notes, and custom enzyme sets. These live in segment types that community parsers skip, so they are silently absent rather than mangled.
- Worth checking by eye: a feature that wraps the origin of a circular plasmid. This is the classic place for an off-by-one or a split feature, because it is the one case where a feature's end coordinate is numerically smaller than its start. Look at the map across position 1 before you trust it.
- Not a format issue at all: whether the annotations were right in the first place. Features in a .dna are whatever the person who made the file drew or auto-detected. Inheriting a file does not mean inheriting a verified map.
Sanity-check the construct once it opens
Once you can read the file, spend two minutes confirming it is the construct you were told it is, especially if it arrived without a paper trail. Three checks catch most surprises.
First, does the length match what you expect? A vector-plus-insert that comes in 500 bp short of the number in the email is worth a conversation before you order primers against it. Second, do the resistance marker and origin match the plasmid's stated backbone and the antibiotic you were told to use? Re-running auto-annotation against a signature library, rather than trusting the inherited labels, will tell you what the sequence actually contains. Third, if you are about to clone with it, check the enzyme sites you plan to use are unique in the full construct — not just present in the region you care about.
If the file arrived with no annotations at all, or you do not trust the ones it has, running it through the Plasmid Annotator gives you a fresh set derived from the sequence itself rather than from the sender's assumptions.
How to not be on this page again
The reason this problem keeps happening is that a lab standardises on one desktop application and its native format becomes the default way sequences get emailed around. Native formats are fine for working files and a poor choice for anything that leaves the building.
When you send a plasmid to someone outside your immediate group, send GenBank. It is text, it is specified, it opens everywhere, and it carries your annotations. If the recipient uses SnapGene they can import it in one step and lose nothing. When you archive a construct in a shared drive or attach it to a paper, do the same, for the same reasons plus one more: a format that only one commercial application reads is a format your data can be stranded in.
Frequently asked questions
Can I open a .dna file without installing anything?
Yes. SeqBench's SeqStudio imports SnapGene .dna files directly in the browser, with no install and no account, and shows the sequence with its features on a circular or linear map. It also imports GenBank (.gb/.gbk, including Benchling's exports) and can export both formats back out.
Is SnapGene Viewer still free?
Yes, though it is no longer a separate download. SnapGene and SnapGene Viewer have been merged into a single application: you install SnapGene, and without a licence it runs in a free Viewer mode where you can view, annotate and share sequence files. Editing, aligning and cloning are the licensed features.
How do I convert a .dna file to GenBank?
Any of three ways: import the .dna into SeqStudio and export GenBank; open it in SnapGene and use its GenBank export; or read it with Biopython (Bio.SeqIO.parse(handle, "snapgene")) and write the record out as GenBank. All three preserve the sequence, the topology and the feature table.
Can Biopython write .dna files?
No. Biopython's SnapGene support is read-only — the format has been readable since Biopython 1.75, but there is no writer, so you cannot use Bio.SeqIO to produce a .dna. To hand a collaborator a file in their native format you need a tool that writes it, such as SeqStudio's "Export .dna", or send GenBank and let them import it.
Why can I see some readable text if I open a .dna in a text editor?
Because the feature and primer annotations are stored as XML — actual plain text — inside the binary container, and the sequence itself is stored as ASCII letters. So feature names and a long run of ACGT are genuinely visible among the noise. It is not a reliable way to extract the record, though: you cannot tell from that view where the sequence begins and ends, whether the molecule is circular, or what coordinates each feature occupies.
Will renaming the file to .gb or .fasta let another program open it?
No. The extension only tells your operating system which application to launch; it says nothing about the bytes in the file and changing it does not change them. A GenBank parser will look for a LOCUS line, a FASTA parser will look for a ">" line, and both will hit binary data and fail. You need something that actually decodes SnapGene's format.
What gets lost converting a .dna file to GenBank?
The sequence, topology, features and usually the saved primers all survive. What is typically dropped is everything specific to working inside SnapGene — saved alignments, the edit history, free-text notes, and custom enzyme sets — because those live in segment types that reverse-engineered parsers skip. Check any feature that wraps a circular plasmid's origin by eye, since that is where coordinate bugs show up.
Related references
Related tools
Type or paste a sequence and edit it directly — every feature remaps live as you insert, delete, or replace bases, with undo/redo and GenBank import/export.
Paste a GenBank record and see an annotated circular or linear map with a feature table.
Auto-detect promoters, tags, origins and resistance markers in a plasmid, then run a deep scan against pLannotate's full feature databases.
Convert between FASTA, GenBank and tab-separated formats, and extract CDS or protein sequences.