Is Your Raw DNA File Complete? Seven Checks

You have downloaded your raw data from 23andMe, AncestryDNA or MyHeritage, and before you hand it to anything that will analyse it you want to know one thing: is this file actually complete? It is a fair question. Downloads get interrupted, exports get cut short, and a file that opens perfectly well can still be missing most of your genome.

This is a checklist you can run yourself in about five minutes with nothing more than a text editor. It covers the seven things that actually go wrong, how to tell each one apart, and what to do about it.

Why a raw DNA file goes wrong in the first place

Nothing is wrong with the measurement. The laboratory read your sample once and the result is fixed. What goes wrong is everything that happens between the vendor's server and your hard drive, and there are only a few ways it can fail.

• An interrupted download. The most common fault by a wide margin. A dropped connection leaves you with a file that is valid text and valid format for as far as it goes, and simply stops. Nothing warns you.
• Unzipping and re-zipping. Every time a file is extracted and recompressed, usually by someone trying to be helpful, there is a chance of a mangled archive or a re-encoded text file.
• Opening it in a spreadsheet and saving. This one is quietly destructive and is covered in its own section below.
• A partial export. Some vendors offer more than one download, for instance autosomal data separately from X or mitochondrial data. Take the wrong one and the file is complete but incomplete for your purpose.
• A genuinely poor sample. Rare, and distinguishable from the others because the file is full length but a large fraction of its genotypes are blank.

Check 1: the file size

Start here, because it catches most problems in two seconds. Look at the file size in your file manager.

A complete array file uncompressed sits at roughly 15 to 25 MB. As the vendor's .zip it is usually 4 to 8 MB, because plain text compresses well. Those are the numbers to expect from any current consumer test.

A file of 200 KB, or 2 MB, is not a small genome. It is a large genome that stopped early. Download it again, on a stable connection, and compare the two sizes.

Size alone is not proof of health, because a file can be full length and still be the wrong export. But a file that fails this check needs no further investigation.

Check 2: the header block

Open the file in a text editor and look at the top. Every vendor writes a header of comment lines, each beginning with a hash symbol, before the data starts. It names the vendor, often the date of the export, and crucially the genome build the coordinates are written against.

If there is no header at all and the file begins straight away with rows of rsids, something has stripped it. That is a signal the file has been through a spreadsheet or an editing step, and it matters because a service receiving your file uses that header to decide how to read the rest.

While you are there, note the build. Consumer vendors have generally reported against GRCh37, also written hg19. Some newer exports use GRCh38. Neither is wrong; they simply number positions differently, and the receiving software has to be told which it is.

Check 3: four fields per row

Scroll past the header to the first real data rows. You should see four pieces of information per line: an identifier beginning with rs, a chromosome, a position number, and a genotype of one or two letters.

23andMe separates those with tabs. AncestryDNA uses tabs and splits the genotype across two columns, one letter each. MyHeritage and FamilyTreeDNA use commas and wrap values in quotation marks. All four layouts are normal and all are readable.

What is not normal is a row with two fields, or a genotype column that is empty all the way down. Either means the file has been reformatted by something that did not understand it.

Check 4: the row count

This is the check that separates a truncated file from a complete one with certainty. Count the lines.

On macOS or Linux, open a terminal in the folder and run wc -l followed by the filename. On Windows, PowerShell will do it with Get-Content filename | Measure-Object -Line. Either way you want a number in the region of 600,000 to 900,000, allowing for the header.

The exact figure depends on the vendor and on which version of the chip you were tested on, and older tests legitimately report fewer markers than recent ones. A result well under half a million from a test taken in the last few years is a strong sign the download was cut short.

If you would rather not use a terminal, a good text editor will show the total line count in its status bar once the file has finished loading.

Check 5: the no-call rate

Search the file for a double dash. Those are positions where the array could not make a confident call. Every file has some and that is entirely normal: arrays are physical measurements and a small fraction of probes fail on any given sample.

What you are looking for is proportion. A scattering of no-calls through an otherwise full file is healthy. A file where a large share of the genotype column is dashes points at a sample that did not yield enough usable DNA, and that is not something a second download fixes. It is a conversation with the vendor, who will usually re-run or re-collect.

Check 6: chromosome coverage

Search for the chromosome values near the end of the file. You want to see rows for chromosomes 1 through 22, then X, and then, depending on vendor and on your sex, Y and MT.

This check catches the partial export. If the file ends at chromosome 22 with no X at all, you have the autosomal export only. If there is no MT, mitochondrial lineage analysis cannot be done from this file whatever else is in it. If you are male and there are no Y rows, the same applies to paternal lineage.

Note that a female file having almost no Y rows is correct and not a fault.

Check 7: never save it from a spreadsheet

This deserves its own check because it is the one failure people cause themselves and then cannot see.

Opening a raw DNA file in a spreadsheet to look at it is harmless. Saving it from a spreadsheet is not. Spreadsheets interpret values, and genetic data is full of things that look like something else. Chromosome and position combinations can be read as dates. Leading zeros vanish. Some genotype values are helpfully converted into other types entirely. Older spreadsheet versions also cap the number of rows they will hold, which silently discards the tail of your file.

The damage is invisible on screen, which is what makes it dangerous. If you have ever saved your file from a spreadsheet, discard that copy and download a fresh one.

What a good file looks like, by vendor

• 23andMe A tab separated .txt inside a .zip, header lines beginning with a hash, four columns, genotype as two letters together.
• AncestryDNA A tab separated .txt inside a .zip, a longer header, and the genotype split into two single-letter columns rather than one.
• MyHeritage A comma separated .csv inside a .zip, values in quotation marks.
• FamilyTreeDNA One compressed .csv.gz file, the Build 37 Concatenated Raw Data, which holds autosomal and X data together. Our FamilyTreeDNA download guide walks through it.
• Living DNA A tab separated text export, which may report a different marker count from the others.

All of these are readable, and all of them should be left inside the archive the vendor gave you.

Files that pass every check and still cannot be analysed

Two cases are worth knowing about, because they look like a broken file and are not.

The first is a file from a very old test. Early chips reported substantially fewer positions, and while such a file is perfectly intact, there is less of it to work with. Analysis is still possible and the result is still useful; it is simply built on fewer markers.

The second is a health or trait report rather than raw data. Several vendors let you download a PDF or a summary spreadsheet of conclusions, which is not the same thing as the measurement. If your download is a few hundred kilobytes and reads in plain English, you have the report. Go back and look specifically for the words raw data in the vendor's download section.

What to do when a check fails

• Size or row count too low Download again on a stable connection. This fixes the large majority of cases.
• No header, or odd column layout Discard the copy you have and take a fresh one from the vendor. Do not try to repair it by hand.
• Missing X, Y or MT Go back to the download page and check whether a separate export covers them.
• A large share of no-calls Contact the vendor. This is a sample quality issue, not a file issue.
• You only have a PDF report Look again for the raw data download, which is usually in a different place from the reports.

If you would like a straight answer rather than running the checklist, any service that accepts raw data uploads has to validate the file before it processes it. Ours reports back what it found in your file, including the marker count and the build, so you can see for yourself whether the upload was read correctly. You can upload your file and have it checked without committing to anything further.

Keep the good copy

Once you have a file that passes, keep it somewhere you control rather than only inside the vendor's website. The analysis can always be redone, and improves as reference panels grow. The sample cannot be re-read once an account closes, which is the lesson of the last two years in this industry. If you tested with 23andMe, it is worth checking whether that download is still available.

Frequently Asked Questions

How big should a raw DNA file be?

Uncompressed, a complete consumer array file is usually 15 to 25 MB; zipped it is typically 4 to 8 MB. A file of a few hundred kilobytes is almost always a truncated download rather than a small genome, and should be downloaded again.

How many markers should be in my raw DNA file?

Expect somewhere in the region of 600,000 to 900,000 rows depending on vendor and chip version. Well under half a million from a current test usually means the download was interrupted or only part of the data was exported.

What percentage of no-calls is normal?

A small share of positions failing to call is routine on every array. A file where a large fraction of genotypes are two dashes points at a poor sample rather than a bad download, and the vendor is the right place to ask for a re-run.

Can I still use my raw DNA file if some markers are missing?

Usually yes. Ancestry analysis reads hundreds of thousands of positions together, so it tolerates scattered gaps well. What it does not tolerate is a file that has lost whole chromosomes or most of its rows.

Does unzipping the file matter before I upload it?

No. Keep the .zip as the vendor gave it to you. Unzipping and re-zipping is where files most often get mangled, and services that accept raw data, ours included, read the original archive directly.

Conclusion

Seven checks, five minutes, one text editor. Size, header, column layout, row count, no-call rate, chromosome coverage, and never saving from a spreadsheet. Those seven catch essentially everything that goes wrong between a vendor's download button and a usable file.

The point of running them is that a truncated file fails quietly. It opens, it looks like DNA, and it will even produce a result if something analyses it, just a worse one built on a fraction of your markers. Two minutes of checking is cheaper than wondering later whether the answer you got was the answer your genome actually supports.

Read next: What raw DNA data is, and how to read the file.