How to download raw sequencing data (FASTQ) from a GEO dataset

You found the perfect study on GEO, you want to re-analyse it from scratch — and then you hit the wall every biologist hits: where are the actual FASTQ files? The GEO page shows processed tables and a RAW.tar that turns out to be full of count matrices, not reads. Here's why, and the fastest way to get the real raw data.

Why GEO doesn't hand you FASTQ directly

This trips up almost everyone. GEO (Gene Expression Omnibus) is a processed-data archive. When authors submit a sequencing study, GEO stores the processed results — count matrices, normalised values, supplementary tables. The raw sequencing reads live in a different database: the Sequence Read Archive (SRA), mirrored by the European ENA.

So a GEO series (a GSE accession) is linked to raw reads, but the FASTQ files themselves sit in SRA/ENA under a different accession. To get them, you have to follow the chain:

The manual way (and why it's painful)

Done by hand, it looks like this:

1. Open the GSE page on GEO, scroll to “Relations”, and find the SRA link (an SRP accession).
2. Land in the SRA, click through to the SRA Run Selector.
3. Download the accession list, then use prefetch + fasterq-dump from sra-tools to pull and convert each run — which is slow, needs installation, and produces huge intermediate .sra files.

The easy way: jump straight to ENA

Instead of clicking through five pages, go from the GEO series to its ENA raw-reads page in one hop:

1. Search your dataset in the GEO Dataset Finder.
2. For any sequencing series, the result carries a “Raw reads · ENA” link.
3. Click it — you land on the ENA browser page for that study, where every run's .fastq.gz is listed with direct download links.

The Finder reads the GEO→SRA relationship from NCBI's own metadata, so the ENA link is resolved for you — no digging through “Relations”, no Run Selector, no guessing accessions. And because the download is a direct browser-to-ENA link, nothing is proxied or slowed down.

Once you're on ENA

The ENA study page is a table with one row per run. The columns you care about are: Run accession (SRR/ERR…), FASTQ FTP (the actual download links), Read count, and Library layout. That last one matters — a single-end run gives one file (SRR….fastq.gz), a paired-end run gives two (SRR…_1.fastq.gz and SRR…_2.fastq.gz) that you must keep together and pass to your aligner as a pair.

A few clicks is fine for one or two runs. But a real study has 6, 20, sometimes 200 runs — nobody clicks 200 links by hand. That's where ENA's bulk options come in.

1. Grab the whole file list in one go

On the study page, open “Download report: TSV” (top-right of the results table). You get a spreadsheet with a fastq_ftp column holding every FASTQ URL, semicolon-separated for paired runs. This is your download manifest. Prefer the command line? ENA has an API that returns the same list — swap in your study accession (the PRJNA… / PRJEB…):

# Get every FASTQ URL for a study, one per line
curl -s "https://www.ebi.ac.uk/ena/portal/api/filereport?accession=PRJNA398089&result=read_run&fields=run_accession,fastq_ftp&format=tsv" \
  | cut -f2 | tr ';' '\n' | grep fastq > urls.txt

2. Bulk download with wget

Once you have the URL list, wget pulls them all. -i reads URLs from the file, -c resumes half-finished files if the connection drops (essential for big FASTQs):

# Download every file in urls.txt, resume on failure
wget -c -i urls.txt

# …or a few known runs directly
wget -c ftp://ftp.sra.ebi.ac.uk/vol1/fastq/SRR590/003/SRR5906453/SRR5906453_1.fastq.gz
wget -c ftp://ftp.sra.ebi.ac.uk/vol1/fastq/SRR590/003/SRR5906453/SRR5906453_2.fastq.gz

3. Faster: curl, or Aspera for very large studies

curl works identically if you prefer it (-O keeps the remote filename, -C - resumes):

curl -O -C - ftp://ftp.sra.ebi.ac.uk/vol1/fastq/SRR590/003/SRR5906453/SRR5906453_1.fastq.gz

For very large downloads (whole-genome studies, hundreds of GB), plain FTP can be slow. ENA also serves the same files over Aspera (ascp), which is dramatically faster on high-latency links — the TSV report includes an fastq_aspera column with those paths. It needs the free Aspera CLI installed, so it's worth it only when FTP is genuinely the bottleneck.

Sanity-check what you downloaded

Before you burn compute on alignment, confirm the files aren't truncated. A valid gzipped FASTQ passes an integrity test, and its line count should be a multiple of four (four lines per read):

# 0 = intact; any error = re-download with wget -c
gzip -t SRR5906453_1.fastq.gz

# read count = lines / 4
echo $(( $(zcat SRR5906453_1.fastq.gz | wc -l) / 4 )) reads

Cross-check that read count against the Read count column on the ENA page — if they match, the file is complete and you're ready to align.

New to the file formats you'll get back? Read the biologist's guide to sequencing file formats.