IGV vs UCSC Genome Browser: Which Tool Should You Use

By Dr. Zubair Khalid, DVM, MS, PhD · 2026-11-10

IGV (Integrative Genomics Viewer) is a desktop application for interrogating your own alignment, variant, and coverage files against a reference genome, while the UCSC Genome Browser is a hosted web service for viewing a locus inside a very large public annotation collection. The one-sentence difference is that IGV answers "what do my reads and calls look like at this position" and UCSC answers "what is already known about this position."

The rule of thumb: if the data is local, large, private, or still being quality-checked, open IGV. If the question depends on public annotation, a stable shareable link, or a dozen orthogonal tracks, open UCSC. Most experienced groups use both, often in the same afternoon, because the two tools are complementary rather than competitive.

This guide explains what each tool actually is, compares them on the criteria that decide real choices, walks through worked scenarios, and covers the file formats and mistakes that trip people up. The file format section matters more than it looks. A large share of "the browser is broken" reports turn out to be an unindexed BAM, a chromosome naming mismatch, or a FASTQ file loaded where an alignment was expected.

What IGV Is, on Its Own Terms

IGV is a Java desktop application. You install it on your laptop or workstation, point it at a reference genome, and load tracks from local disk or from a remote URL. Nothing is uploaded to a central server unless you deliberately choose a hosted option. That design choice is the source of most of IGV's strengths: private data stays private, large files stream from disk without a network round trip, and the interface responds quickly when you scroll or zoom.

The core view is a pileup. Each aligned read is drawn as a horizontal bar, mismatches are colored, insertions and deletions are marked, and a coverage track summarizes depth across the visible window. A separate panel shows gene models, and additional tracks can carry variant calls, copy number segments, signal, or intervals. Because BAM files are read directly, the coverage track is computed on the fly rather than precomputed, which is the same design pattern seen in browser tools that build read coverage, SNPs, and indels dynamically from BAM input [1].

IGV also handles strand-aware display. In a strand-specific RNA-seq library, reads from the positive-strand transcript can be drawn above a central line and reads from the negative-strand transcript below it, which makes novel exon and intron borders easier to spot [1]. The related RNASeqBrowser project explicitly integrates UCSC Genome Browser conventions with NGS visualization tools such as IGV, which is a useful reminder that these tools are frequently combined rather than replaced [1].

Several practical features make IGV the default for read-level inspection:

• Load BAM, CRAM, VCF, bigWig, BED, GFF, GTF, and related formats in one session.
• Color alignments by strand, read pair orientation, insert size, or base.
• Group and sort reads by tag, which is essential for amplicon and tumor-normal work.
• Take snapshots of the current view and drive them from a batch script.
• Send commands to a running instance through a port, which enables scripted navigation and image capture.
• Load a custom genome from a FASTA file when no standard build exists.

The last point is important for non-model organisms, for de novo assemblies, and for anyone working on a draft genome that is not in a public browser. A local FASTA plus a GFF3 annotation file is enough to start browsing [2]. IGV is not only a viewer for finished analyses. Pipelines routinely write their output as tracks intended for IGV and UCSC, which reflects how central the viewer is to the interpretation step [3].

What the UCSC Genome Browser Is, on Its Own Terms

The UCSC Genome Browser is a web application hosted by the University of California, Santa Cruz. You open it in a browser, choose an assembly, type a coordinate or a gene name, and land on a view that already has dozens of annotation tracks available. The tracks are curated and hosted. You do not supply them, and you do not need to download them before you start.

The feature that made UCSC a standard is the custom track. UCSC introduced the custom track concept, which let researchers visualize gene expression at a particular locus from multiple experiments at the same time [1]. That idea is now everywhere. A custom track is a line of text that points at a file or embeds data, and it can be pasted into a browser form or served from a track hub. Once the track is loaded, it behaves like a native annotation track, which means it can be combined with conservation, ENCODE, RefSeq, ClinVar, and hundreds of other datasets in a single view.

UCSC is also the reference implementation of a genome database. The assembly list is huge, the gene models are versioned, and the coordinate system is stable across releases. That stability is why links to UCSC views keep working years later, which is a real advantage for papers, supplements, and teaching material. The browser is not just a picture. It exposes a Table Browser for extracting intervals and a REST API for programmatic queries, and its gene models are commonly queried by downstream visualization scripts to keep figures reproducible [4].

UCSC handles signal data well because bigWig is a first-class format. BigWig is a common file format supported by many genome browsers, and it stores coverage in an indexed binary structure that allows a browser to fetch only the region being viewed [5]. That is why a bigWig track can be plotted across a whole chromosome without transferring the whole file. The same logic applies to bigBed for interval data. If your data is signal or intervals and you want it shareable, UCSC is often the shortest path from file to stable link.

The browser is not optimized for huge alignment files. It can display BAM tracks through custom tracks and track hubs, and it does, but the experience depends on network latency and on the size of the region being viewed. For a single locus, it works. For scrolling across a chromosome with twelve BAMs loaded, it will feel slower than a local IGV session.

IGV vs UCSC Genome Browser: Side-by-Side Comparison

The table reduces to a single trade-off. IGV gives you speed and privacy on data you own. UCSC gives you context and permanence on data the community maintains. Neither tool is strictly better, and the difference between IGV and the UCSC Genome Browser is mostly about where the data lives and what question you are asking.

The Criteria That Decide Real Choices

Data Type and File Formats

If the primary data is aligned reads, IGV is the natural choice. A BAM file with a matching index loads in seconds, and the pileup view is the standard way to check a variant call, a splice junction, or a suspicious region. The same is true for CRAM, which is a reference-based compressed alignment format designed to reduce storage. IGV reads both.

If the primary data is coverage signal, both tools work. A bigWig file can be loaded into IGV as a track or referenced by a UCSC custom track line [5]. The difference is in the sharing model. A bigWig that lives on a web server can be shared with a URL. A bigWig on your laptop cannot, unless you move it or take a screenshot.

If the primary data is a variant call set, both tools work, but the surrounding context differs. IGV lets you click a variant and immediately see the reads underneath. UCSC lets you click a variant and immediately see the overlapping ClinVar entries, conservation scores, and regulatory tracks. The choice depends on whether the next question is "is this call real" or "what is known about this position."

Local Versus Hosted Data

Local data is the strongest argument for IGV. Unpublished BAMs, patient samples, and pre-release assemblies should not be uploaded to a third-party service. IGV reads them from disk, and no network transfer occurs. That property alone makes IGV the default in clinical and industrial settings where data governance matters.

Hosted data is the strongest argument for UCSC. Public annotation tracks are already there. You do not need to download a conservation track, a ENCODE track, or a gene model set. You turn them on. The time savings are substantial when the question is annotation-driven rather than sample-driven.

Speed, Scale, and Memory

IGV is a Java application, so its memory ceiling is set by the Java heap. Loading many large BAMs at once can exhaust the default heap, and the fix is to raise the maximum heap size when launching the application, for example with a larger -Xmx value. That is standard Java behavior, not a quirk of IGV. The practical rule is to give the application enough memory for the files you plan to open and to close sessions you no longer need.

UCSC performance is dominated by network and by the number of tracks turned on. A single bigWig track across a gene-sized window is fast. Dozens of tracks across a chromosome-sized window is slow, and the browser will often warn you before it tries. Zooming in reduces the amount of data requested and usually restores responsiveness.

Sharing and Reproducibility

UCSC wins on sharing. A URL encodes the assembly, the position, the tracks that are turned on, and the display mode. Send that URL to a collaborator and they see the same view. Saved sessions and track hubs extend the same idea to larger track collections. For figures in papers and for teaching, this is hard to beat.

IGV sharing is more manual. You can save a session file, but the session references local file paths, so a collaborator needs the same files in the same locations or must relink them. You can take snapshots, and you can script them. You can also use hosted IGV options, but the simplest reproducible artifact from an IGV session is usually an image plus a description of the genome build and track sources. That is acceptable for internal work and less ideal for public supplements.

Genome Assemblies and Annotation Depth

UCSC has the deeper hosted assembly collection. For human, mouse, and the major model organisms, the annotation is extensive and versioned. For less common organisms, coverage varies, and you may need a custom genome.

IGV handles custom genomes well. You provide a FASTA file and, optionally, a GFF3 or GTF annotation, and the tool builds a genome from them. That flexibility is why IGV is common in non-model organism labs and in assembly quality control. A tool that flags questionable assembly regions can output GFF3 so that the regions can be imported into a local genome browser for inspection by location and nucleotide [6]. That workflow depends on a browser that accepts a custom genome and a GFF3 track, which is exactly what IGV provides.

Automation and Programmatic Access

Both tools can be automated, but in different ways. IGV supports batch scripts that load files, navigate to coordinates, and write snapshots. That is useful for generating hundreds of locus images for review. IGV also accepts commands through a port, which allows an external script to drive a running instance.

UCSC exposes a REST API and a Table Browser. The API returns track data for a region as text or JSON, which is useful for building custom reports. The Table Browser returns intervals for a track, which is useful for overlap analysis. Scripts that query UCSC for gene models to keep plots reproducible are a known pattern [4], and the same approach works for any hosted track.

Bioinformatics File Formats You Need to Know

Most browser problems are format problems. The list below covers the formats you will actually encounter. The general point is that browsers display coordinate-anchored data, and not every file format carries coordinates. A review of common genomic file formats and visualization resources makes the same distinction between formats that store raw reads and formats that store mapped or annotated features [7].

FASTA vs FASTQ

FASTA is a text format for sequences. Each record begins with a > header line, followed by sequence lines. There are no quality scores. FASTA is used for reference genomes, protein sequences, and assembled contigs. A reference genome loaded into a browser is usually a FASTA file, and a protocol for setting up a genome browser describes exactly that step: load the reference from a FASTA file, then add annotation from a GFF3 file [2].

FASTQ is a text format for sequencing reads. Each record has four lines: an @ header, the sequence, a + separator, and a quality string. The quality string encodes per-base Phred scores as ASCII characters, typically offset by 33. FASTQ is the output of a sequencer, and it is the input to an aligner.

The practical difference is coordinates. FASTA can represent a reference that reads are mapped to. FASTQ represents reads that have not been mapped yet. Neither IGV nor UCSC is designed to display a FASTQ file as a track, because there is nothing to anchor it to the genome. Align the reads first, then load the resulting BAM or CRAM.

Alignment Formats: SAM, BAM, CRAM

SAM (Sequence Alignment/Map) is the text format for aligned reads. BAM is its binary, compressed equivalent. CRAM is a newer compressed format that stores reads relative to the reference, which reduces file size further. All three carry the same core information: read name, flags, reference name, position, mapping quality, CIGAR string, and sequence.

BAM and CRAM files need an index before a browser can jump to a region. The common index is .bai for BAM and .crai for CRAM, with .csi as an alternative for large references. A BAM without an index will load slowly or fail to navigate, and this is one of the most common causes of a "broken" IGV session.

Variant Formats: VCF

VCF (Variant Call Format) stores variant sites with a header block and one line per variant. It is the standard output of variant callers and the standard input to downstream annotation. VCF files are commonly indexed with tabix, producing a .tbi file, or with a CSI index. Tools that accept VCF alongside BAM are widespread in cancer and germline analysis [8], and multi-format support including VCF is a standard expectation for cohort visualization tools [9]. In a browser, VCF appears as a track of variant sites, and clicking a site in IGV usually reveals the underlying reads.

Interval Formats: BED, GFF3, GTF

BED (Browser Extensible Data) is a tab-delimited interval format. It is zero-based and half-open, meaning the start coordinate is included and the end coordinate is excluded. That convention is a frequent source of off-by-one errors when BED coordinates are compared with one-based formats.

GFF3 (General Feature Format version 3) and GTF (Gene Transfer Format) are one-based annotation formats. They describe genes, transcripts, exons, and other features. A genome browser can load a GFF3 file as an annotation track, which is the standard way to add gene models to a custom genome [2]. GFF3 output is also a common way for analysis tools to hand questionable regions to a local browser for inspection [6].

Signal Formats: Wig, bigWig, bigBed

Wig is a text format for coverage signal. bigWig is its binary, indexed successor, and it is the format most browsers prefer for signal tracks [5]. bigBed is the equivalent for interval data. Both are designed so that a browser can request only the visible window, which is why they remain fast across large genomes. Visualization scripts often produce bigWig output because it is portable across browsers and easy to plot [5], and tools that generate IGV-style track plots from bigWig files rely on the same indexed structure to stay fast [4].

Worked Scenarios

Scenario 1: Checking a Variant Call in Your Own BAM

You ran a variant caller on twelve samples and want to inspect a suspicious missense call. Open IGV, load the reference genome, load the twelve BAMs and their indexes, and navigate to the locus. Sort reads by base, color by strand, and look at the pileup. If the call is real, you will see supporting reads in the correct orientation and a coverage profile consistent with the rest of the region. If it is an artifact, you will see reads concentrated at one end, a strand bias, or a collapse of mapping quality. This is the scenario where IGV is clearly the right tool. It is fast, local, and built for exactly this question.

Scenario 2: Checking a Splice Junction in RNA-seq

You have a strand-specific RNA-seq experiment and a candidate novel exon. Load the BAMs in IGV, enable strand-aware coloring, and zoom to the junction. Reads from the positive-strand transcript appear above the center line and reads from the negative-strand transcript below it, which makes the strand assignment visible at a glance [1]. The coverage track shows the drop across the junction, and the splice junction track shows the supporting split reads. This kind of read-level interpretation is not what UCSC is optimized for.

Scenario 3: Asking What Is Known About a Promoter

You have a candidate regulatory variant and want to know what public data says about the region. Open UCSC, navigate to the locus, and turn on ENCODE tracks, conservation, regulatory elements, and ClinVar. The value here is context, not reads. You are not checking whether a call is real. You are checking whether the region has known biology. A stable URL captures the exact track combination, which is useful when you send the view to a collaborator or include it in a supplement.

Scenario 4: Browsing a Non-Model Organism Assembly

You assembled a draft genome for a non-model species and want to inspect a region. Load the assembly FASTA into IGV as a custom genome, add a GFF3 annotation, and load the BAM of reads mapped back to the assembly. This works because IGV accepts arbitrary FASTA references. UCSC can host custom genomes, but the setup is more involved than a local IGV session, and for unpublished assemblies the local option is the practical one.

Scenario 5: Generating Many Locus Snapshots

You need images for 200 candidate variants. Running each one by hand is slow and error-prone. IGV batch mode lets you script the navigation and snapshot steps, which makes the process reproducible and auditable. This is a common workflow in clinical review and in manuscript preparation. The output is a directory of images plus a script that documents exactly which coordinates and tracks were used.

Scenario 6: Sharing a View with a Collaborator Who Has No Setup

A clinician or collaborator wants to see a locus but does not have IGV installed and does not want to download files. A UCSC URL is the simplest answer. It opens in a browser, shows the tracks you selected, and requires no installation. If the data includes unpublished BAMs, this is not an option, and the right answer is a screenshot or a session file with clear instructions.

Common Mistakes and Limitations

Loading FASTQ into a browser. IGV and UCSC display coordinate-anchored data. FASTQ reads have no coordinates until they are aligned. Align first, then load the BAM or CRAM. A related mistake is loading a FASTA reference as if it were a track. A reference is a genome, not an annotation track, and it is loaded through the genome setup rather than the track menu.

Missing index files. A BAM without a .bai and a VCF without a .tbi will not navigate reliably. The browser may load the file but fail when you jump to a locus. Generate the index at the same time you generate the file, and keep the two together.

Chromosome naming mismatches. UCSC-style names use a chr prefix, such as chr1. Ensembl-style names often drop the prefix, such as 1. A BAM aligned to a FASTA with one naming convention will not display correctly against a genome built with the other. The track appears empty or the browser reports that the chromosome is not found. Check the sequence dictionary before you blame the viewer.

Wrong genome build. hg19 and hg38 are different assemblies. GRCh37 and GRCh38 are different assemblies. A BAM aligned to one build will produce nonsense if displayed against another. The pileup may look plausible at low zoom and wrong at high zoom, which makes this error easy to miss. Confirm the build in the BAM header and match it to the genome loaded in the browser.

Coordinate system confusion. BED is zero-based and half-open. GFF3, GTF, and VCF are one-based. A one-base shift is easy to miss in a large view and obvious only when you compare against a known feature. When a BED track looks shifted by one base, the coordinate convention is the first thing to check.

Treating the browser as an analysis tool. IGV and UCSC are viewers. They do not replace a variant caller, a peak caller, or a statistical test. A pileup that looks convincing is not evidence of a true variant. The call still needs a caller, a quality filter, and, for clinical work, orthogonal validation. The same caution applies to UCSC. A track that overlaps your variant is a hypothesis, not a result.

Assuming the gene model is complete. Gene annotation is a representation, not a complete description of biology. Alternative transcripts, unannotated exons, and rare isoforms exist. A variant that falls outside an annotated exon is not necessarily noncoding in every transcript. Check multiple transcript models before drawing a conclusion.

Overloading a UCSC view. Turning on dozens of tracks across a chromosome-sized window will be slow, and the browser may refuse to render. Zoom to a gene-sized window, turn on only the tracks you need, and use track hubs for large collections rather than pasting many custom tracks.

Custom track syntax errors. A custom track line has a strict format. A missing quote, a wrong type, or an unreachable URL will produce an error or an empty track. Test the URL in a browser first, then paste the track line. BigWig and bigBed tracks must point at indexed binary files, not at wig or bed text files, if you want them to load quickly [5].

Sharing IGV sessions without checking paths. An IGV session file references local file paths. A collaborator who receives the session but not the files will see empty tracks. Either bundle the files, relink the tracks after opening, or share a screenshot instead.

Assuming remote BAM access is fast. UCSC and IGV can both read BAM files over HTTP using range requests. This works, but it depends on the server supporting range requests and on network latency. For large files, local access is usually faster.

Using a viewer for data governance decisions. A browser does not decide whether data can be shared. If the data is identifiable or covered by a data use agreement, a public URL is not appropriate regardless of which tool you use. Decide the sharing policy before you generate the link.

Frequently Asked Questions

Can IGV or the UCSC Genome Browser open a FASTQ file directly?

No. Both tools display data in genomic coordinates, and raw FASTQ reads have no coordinates until they are aligned. Align the reads to a reference first, then load the resulting BAM or CRAM file.

Which tool is better for viewing RNA-seq reads?

IGV is better for read-level RNA-seq inspection. It shows the pileup, strand orientation, splice junctions, and coverage in one view, and it handles strand-specific libraries explicitly [1]. UCSC is better for placing an RNA-seq signal track next to public annotation.

Can I share a UCSC Genome Browser view with a collaborator?

Yes. A UCSC URL encodes the assembly, position, and active tracks, so a collaborator sees the same view without any setup. Saved sessions and track hubs extend this to larger track collections.

Can IGV display data from a remote URL?

Yes. IGV can load tracks from HTTP or FTP URLs, including BAM, bigWig, and VCF files, provided the server supports range requests and the file is indexed. Local files are still faster for large datasets.

Do I need to know the genome build to use either tool?

Yes. Both tools require the data and the reference to use the same assembly. A BAM aligned to hg38 must be displayed against hg38, not hg19. Mismatched builds produce plausible-looking but incorrect pileups.

Is IGV suitable for clinical variant review?

IGV is widely used for visual review, but it is a viewer, not a validated clinical decision tool. Clinical interpretation requires a validated pipeline, a variant caller with documented performance, and orthogonal confirmation. IGV supports the review step, not the entire process.

Sources

1. RNASeqBrowser: a genome browser for simultaneous visualization of raw strand specific RNAseq reads and UCSC genome browser custom tracks.
2. Setting Up the JBrowse 2 Genome Browser.
3. Fish the ChIPs: a pipeline for automated genomic annotation of ChIP-Seq data.
4. Trackplot: a fast and lightweight R script for epigenomic enrichment plots.
5. Prioritising positively selected variants in whole-genome sequencing data using FineMAV.
6. BioNanoAnalyst: a visualisation tool to assess genome assembly quality using BioNano data.
7. Online resources for genomic analysis using high-throughput sequencing.
8. pyCancerSig: subclassifying human cancer with comprehensive single nucleotide, structural and microsatellite mutational signature deconstruction from whole genome sequencing.
9. CoMutPlotter: a web tool for visual summary of mutations in cancer cohorts.