# BED File Format: A Practical Guide for Genomic Interval Analysis A BED (Browser Extensible Data) file is a tab-delimited plain-text format that describes genomic intervals as a chromosome name, a start coordinate, and an end coordinate, with optional columns for feature name, score, strand, and exon structure. It is the working language of interval analysis, the format that lets one tool's output become another tool's input without any loss of positional meaning. BED matters because most genomic questions are really interval questions. Does this [transcription factor](/knowledge/molecular-biology/transcription-factor) peak fall inside that promoter? How many sequencing reads land on each exon of a targeted panel? Which copy-number segments overlap a known tumor suppressor? Every one of those questions reduces to comparing two sets of coordinates, and BED is the format built for that comparison. Where FASTA and FASTQ carry sequence, and VCF carries variants, BED carries pure positional structure. That narrow purpose is why it has survived for more than two decades and why nearly every genome browser, bedtools, and alignment utility accepts it. ## What a BED File Is and Why It Matters A BED file is not a sequence file and not a variant file. It is a coordinate file. Each line describes one interval on one reference sequence, and the collection of lines describes a set of regions: promoters, peaks, exons, amplicons, blacklist zones, methylation blocks, copy-number segments, or anything else that can be anchored to a genome. The format originated with the [UCSC Genome Browser](/knowledge/bioinformatics/ucsc-genome-browser-beginner-tutorial-and-tips) as a way to display annotations, which is where the "Browser Extensible Data" name comes from. That origin explains several quirks. BED allows `track` and `browser` header lines that control browser display. BED allows comment lines beginning with `#`. BED allows anywhere from three to twelve columns. And BED uses a coordinate convention that differs from almost every other genomics format, a fact that causes more silent errors than any other single issue in interval analysis. Genomics file formats as a class are specialized, numerous, and often loosely specified [1]. That looseness is a strength during rapid method development and a liability during production analysis, because two tools can both claim to "read BED" while disagreeing about what a given line means. A 2022 study of BED input validation found that of 80 Bioconda software packages examined, 75 achieved less than 70 percent correctness on a purpose-built test suite, with fuzzing uncovering additional errors beyond the manually designed cases [2]. The practical lesson is straightforward. Treat BED as a format you must actively verify, not one you can assume is handled correctly. ## The BED Format at a Glance | Format | What it stores | Coordinate convention | Typical analysis role | |--|--|--|--| | BED | Genomic intervals with optional name, score, strand, blocks | Zero-based start, half-open end | Interval arithmetic, peak sets, panel design, region annotation | | GFF/GTF | Annotated features with nine fixed columns | One-based, closed interval | Gene and transcript models | | VCF | Variants with alleles and genotypes | One-based position of the variant | Variant calling and genotyping | | SAM/BAM | Aligned reads with mapping quality and CIGAR strings | One-based leftmost position | Read alignment storage | | FASTA | Sequences only, with a header line | Not applicable | Reference genomes, protein sequences | | FASTQ | Sequences plus per-base quality scores | Not applicable | Raw sequencing reads | The table is the single most useful mental model. BED and GFF/GTF can both describe exons, but they disagree about where a feature starts. BED and VCF can both describe a single base, but they disagree about how that base is numbered. Those disagreements are mechanical, not conceptual, and they are fixable with discipline. ## Anatomy of a BED Record: Columns 1 Through 12 ### The three required columns The minimum valid BED record has three fields, separated by tabs, not spaces. ``` chr1 1000 2000 ``` - Column 1, `chrom`: the reference sequence name, exactly matching the name used by the reference FASTA and by every other file in the analysis. - Column 2, `chromStart`: the zero-based start coordinate. - Column 3, `chromEnd`: the end coordinate, which is not included in the interval. A three-column BED file is often written BED3. It is the safest interchange format because it contains no optional fields that tools might interpret differently. ### The optional columns, BED6 and BED12 Six-column BED, or BED6, adds name, score, and strand. ``` chr1 1000 5000 geneA 0 + ``` - Column 4, `name`: a feature label. Browsers truncate long names, but downstream tools treat this as an arbitrary string. - Column 5, `score`: a display score conventionally between 0 and 1000. It is not a p-value and not a quality score unless a specific pipeline defines it that way. - Column 6, `strand`: `+`, `-`, or `.` for unknown. Twelve-column BED, or BED12, adds the fields needed to draw a multi-exon feature. ``` chr1 1000 5000 geneA 0 + 1000 5000 0 2 500,400, 0,3600, ``` - Column 7, `thickStart`: where the thick display block begins, typically the start codon. - Column 8, `thickEnd`: where the thick display block ends, typically the stop codon. - Column 9, `itemRgb`: an RGB color such as `255,0,0` for browser rendering. - Column 10, `blockCount`: the number of exons or blocks. - Column 11, `blockSizes`: a comma-separated list of block lengths, with a trailing comma conventionally tolerated. - Column 12, `blockStarts`: a comma-separated list of block start offsets measured from `chromStart`, not from the chromosome. In the example above, the two blocks begin at offsets 0 and 3600 from `chromStart` and are 500 and 400 bases long, so the second block ends at 4000, exactly matching `chromEnd - chromStart`. That internal consistency is the rule that catches most BED12 construction bugs. ## The Zero-Based, Half-Open Coordinate Convention BED uses a zero-based, half-open coordinate system. The first base of a chromosome is numbered 0 in `chromStart`, and `chromEnd` points one base past the last base of the feature. The interval `chr1 0 100` therefore covers the first 100 bases of chromosome 1, which are numbered 1 through 100 in one-based terms. The advantage of half-open coordinates is arithmetic. The length of an interval is always `chromEnd - chromStart`. Two intervals that share a boundary, such as `100 200` and `200 300`, do not overlap, which is exactly what you want when tiling a genome. In a one-based closed system, adjacent features share a base and overlap detection becomes ambiguous. The disadvantage is that BED disagrees with nearly everything else. GFF, GTF, VCF, SAM, and BAM all count from 1. A student who copies a GFF exon start directly into a BED file will shift the feature one base to the right, and the resulting file will still parse cleanly, still produce output, and still be wrong. ### Converting between BED and one-based formats The conversion rules are simple enough to memorize. - GFF/GTF to BED: `bedStart = gffStart - 1`, `bedEnd = gffEnd`. - BED to GFF/GTF: `gffStart = bedStart + 1`, `gffEnd = bedEnd`. - A VCF variant at one-based position `POS` with a single-base REF occupies BED interval `POS - 1` to `POS`. - A SAM record with one-based leftmost position `POS` and reference length `L` occupies BED interval `POS - 1` to `POS - 1 + L`. Tools that convert between these formats handle the shift internally. Tools that merely relabel columns do not. This is precisely the class of edge case that the Acidbio verification system was built to expose, and it is the reason the authors recommended that developers advertise exactly which BED variants their software accepts [2]. ### A worked coordinate example Take a region the analyst describes verbally as "chr1 from base 1001 to base 2000." In one-based closed notation that is chr1:1001-2000, a 1000-base region. In BED it is: ``` chr1 1000 2000 ``` The start is 1000 because the first base of the region is base 1001, and zero-based numbering makes it 1000. The end is 2000 because the region ends at one-based base 2000, and the half-open end is the same number. The length is 2000 minus 1000, which is 1000. All three views agree once the convention is applied consistently. Now suppose a second file marks a peak at chr1:1501-2500. In BED that is `chr1 1500 2500`. The overlap with the first region runs from BED 1500 to BED 2000, a 500-base shared segment. A tool that treated both files as one-based would compute an overlap of 1501 to 2000, a 499-base segment, and every downstream count would drift. ## BED Variants You Will Meet in Practice ### BED3, BED6, BED12, bedGraph, and BEDPE BED is a family, not a single specification. The common members are: 1. **BED3**: coordinates only. Maximum interoperability. 2. **BED6**: adds name, score, and strand. Common for peak calls and blacklists. 3. **BED12**: adds thick blocks and exon structure. Common for gene models and transcript display. 4. **bedGraph**: a four-column format for continuous values such as coverage, with the score in column 4. It is the natural output of coverage calculations. 5. **BEDPE**: paired-end interval format, used for [structural variant](/blog/guides/structural-variant) breakpoints and chromatin loops, where each record holds two intervals rather than one. A file that mixes column counts between lines is not valid BED. It may still load in a permissive parser, but strict parsers will reject it. Because the number of columns defines the variant, an analyst should check the column count of the first data line before assuming a file is BED6 or BED12. ### bigBed and proBed BigBed is a binary, indexed, compressed version of BED designed for random access over web protocols. It is generated from a sorted BED file plus a chromosome sizes file, typically with UCSC's `bedToBigBed`. BigBed is what makes it practical to display millions of intervals in a genome browser without downloading the whole file. proBed is a domain adaptation rather than a variant. It extends BED to carry mass spectrometry proteomics information so that proteogenomic studies can reuse BED-compatible tooling. The developers emphasized that existing genomics tools such as SAMtools and Bedtools, plus several widely used genome browsers, can manipulate and visualize proBed out of the box [3]. The existence of proBed is a useful demonstration of why BED became a de facto standard: its column structure is simple enough to extend without breaking the tools that already read it. ## How BED Files Drive Genomic Interval Analysis ### Sorting and chromosome naming come first Almost every interval operation assumes coordinate-sorted input. Sorting means chromosome order first, then start position numerically within each chromosome. The standard shell idiom is: ``` sort -k1,1 -k2,2n regions.bed > regions.sorted.bed ``` Alphabetical chromosome order puts chr10 before chr2, which is fine for many tools as long as the same order is used throughout, but it breaks tools that expect a specific reference order. For strict control, use a genome file that defines chromosome order and sizes. Chromosome naming is the second prerequisite. A BED file using `chr1` will produce zero overlaps against a file using `1`. There is no error message, no warning, and no indication that anything went wrong. The output is simply empty. Before running any intersection, confirm that both files use the same naming convention and the same reference assembly. Mixing hg19 coordinates with hg38 coordinates is the same failure at a larger scale and produces intervals that are plausible but meaningless. ### The core interval operations The bedtools suite is the reference implementation for BED arithmetic. The operations that cover most workflows are: - **Intersect**: `bedtools intersect -a regions.bed -b peaks.bed > overlaps.bed` returns the portions of A that overlap B. Adding `-wa -wb` reports the original A record alongside the matching B record, which is what you want when you need to know which peak matched which region. - **Subtract**: `bedtools subtract -a regions.bed -b mask.bed > clean.bed` removes masked portions from A. - **Merge**: `bedtools merge -i sorted.bed > merged.bed` collapses overlapping or book-ended intervals into single spans. This is the standard step for turning individual reads into contiguous covered regions. - **Coverage**: `bedtools coverage -a regions.bed -b reads.bed` reports how many B features overlap each A feature, which is the basis for depth calculations over a panel. - **Genome coverage**: `bedtools genomecov -ibam aligned.bam -bg > coverage.bedGraph` converts an alignment file into a bedGraph of per-base depth. - **Closest**: `bedtools closest -a variants.bed -b genes.bed` assigns each A feature to its nearest B feature, which is useful for annotating intergenic positions. ### A worked interval example Consider two small BED3 files. ``` regions.bed chr1 1000 2000 peaks.bed chr1 1500 2500 ``` `bedtools intersect -a regions.bed -b peaks.bed` returns `chr1 1500 2000`, the 500-base shared segment. `bedtools subtract -a regions.bed -b peaks.bed` returns `chr1 1000 1500`, the 500 bases of the region not covered by the peak. `bedtools merge` on the two original files returns `chr1 1000 2500`, a single 1500-base span. These three answers are all correct and all different. Choosing among them is the analysis decision, and it depends on the biological question. For "what fraction of my region is covered by peaks," use intersect. For "which parts of my region are free of peaks," use subtract. For "what is the total footprint of my region and my peaks," use merge. ## BED Across Real Pipelines ### Variant calling and coverage-aware consensus BED is not only a visualization format. It carries analysis logic. ChoCallate, a Nextflow pipeline for consensus germline variant calling, builds coverage awareness into its consensus generation through a BED file, which allows reliable variant identification in reduced-representation data such as RAD-seq and RNA-seq [4]. In a simulated Arabidopsis thaliana dataset containing 10,000 SNPs and 1,000 insertions and deletions across coverage depths from 3x to 50x, the two-vote consensus strategy gave a favorable precision-recall balance, particularly at 3x to 10x, where SNP precision improved without substantial loss of sensitivity [4]. The BED component is what lets the pipeline restrict consensus calls to regions where coverage supports them. ### Copy number simulation and targeted panel design Bamgineer, a tool for introducing allele-specific copy number variants into exome and targeted sequencing data, takes a BAM file plus lists of non-overlapping genome coordinates in BED format to define where gains and losses should be introduced, with an optional VCF defining known haplotypes [5]. The requirement for non-overlapping BED intervals is a practical reminder that simulation, like analysis, depends on clean interval sets. Targeted panel design also runs on BED. The ionflows package computes how many nucleotide flows are needed to cover a set of amplicons, using a BED file of genomic positions as input, and the authors applied it to six amplicon panels used for targeted sequencing in cancer research [6]. The same approach appears in exon capture design. EXONSAMPLER automates sampling of exon sequences and outputs both a list of genomic coordinates in BED format and the corresponding sequences in FASTA format, which is exactly the split between coordinates and sequence that BED and FASTA are each designed to handle [7]. ### Methylation and epigenomic data Methylation pipelines routinely emit BED. The HELP-tagging analysis pipeline supplies results in standard BED and WIG formats so that they can be examined directly in the UCSC Genome Browser [8]. More recent methylation tooling has moved toward specialized formats for compactness, such as the epiread format in wgbstools, which achieves more than 100-fold compression from the input BAM file [9]. The existence of those specialized formats does not remove BED from the workflow. It changes BED's role from bulk data storage to interchange and visualization, which is where its simplicity earns its keep. ### Visualization and search GeNemo accepts functional genomic data in BED, Peaks, and bigWig formats, searches against ENCODE datasets covering epigenomic marks, transcription factor binding sites, and chromatin accessibility, and returns matching genomic regions that can be viewed in a browser or downloaded as BED [10]. CGDV accepts VCF, BED, tab-delimited matrices, CNVnator raw output, and gene fusion output to produce circular genome-wide visualizations [11]. In both cases BED functions as the shared coordinate language that lets heterogeneous inputs be plotted on the same axes. ## BED Among Other Bioinformatics File Formats ### FASTQ vs FASTA, and why neither is a BED The FASTQ versus FASTA distinction confuses newcomers because both store sequence. FASTA stores a sequence with a header line and nothing else. FASTQ stores a sequence with a header line plus a per-base quality string encoded as ASCII characters, which is why FASTQ files are roughly twice the size of comparable FASTA files. FASTA answers "what is the sequence," and FASTQ answers "what is the sequence and how confident was the instrument in each base." A standard next-generation sequencing overview groups FASTQ, FASTA, SAM/BAM, GFF/GTF, BED, and VCF as the six formats that carry most of the data in a sequencing project [1]. The division of labor is clean. FASTQ holds raw reads, FASTA holds references and assembled contigs, SAM/BAM holds aligned reads, VCF holds variants, GFF/GTF holds annotation, and BED holds intervals. A representative bulk RNA-seq protocol moves through exactly this chain: download from SRA, assess with FastQC, trim with Trimmomatic, align with BWA or HISAT2, manipulate with Samtools and Subread, then count reads and normalize to TPM [12]. BED enters that chain when the analyst needs to restrict counting to a defined set of regions, such as exons or a capture panel. The practical consequence is that BED cannot store sequence. If you need the bases under your intervals, you extract them into FASTA: ``` bedtools getfasta -fi reference.fa -bed regions.bed -fo regions.fa ``` That command is the bridge between the coordinate world and the sequence world, and it is the operation most often needed when someone asks whether a BED file can hold sequence information. ### BED vs GFF/GTF, VCF, and BAM The comparison table earlier in this article gives the summary. The operational differences are worth spelling out because they drive real errors. GFF and GTF describe hierarchical features, meaning a gene contains transcripts that contain exons. BED12 can approximate that hierarchy by drawing blocks, but it cannot express parent-child relationships. If your analysis needs transcript-level structure with explicit relationships, GFF/GTF is the right source and BED is a derived display format. VCF describes alleles. A BED interval covering a variant tells you where the variant is, not what it is. Converting VCF to BED loses the REF and ALT fields entirely, which is fine when you only need positional overlap and fatal when you need genotype. BAM describes reads with alignment detail. A BED interval derived from a BAM tells you where reads landed but discards mapping quality, CIGAR strings, and mate information. That reduction is usually the point, because interval arithmetic on millions of reads is far faster than alignment-level arithmetic. ### The wider format landscape The number of specialized formats keeps growing, and each one solves a problem that text-based BED handles poorly at scale. The Indexable Genotype Data format stores genotype data as an uncompressed binary and can be more than 100 times faster and 3.5 times smaller than vcf.gz on biobank-scale whole-genome sequence data [13]. QCatch exports single-cell quantification results in the richly annotated H5AD format used across downstream single-cell tools [14]. OME-Zarr brings cloud-optimized storage to bioimaging through a community next-generation file format specification [15]. SLOW5 and POD5 compete for nanopore raw signal storage, where binary reading performance directly affects basecalling cost [16]. BED sits at the opposite end of that spectrum. It is text, it is human-readable, it is trivially editable, and it is slow at scale. Those properties are why it persists for interchange and why large production BED sets are usually converted to bigBed or bgzipped and tabix-indexed: ``` bgzip regions.bed tabix -p bed regions.bed.gz ``` Indexing does not change the format. It changes whether you can query a 50-million-interval file without reading all of it. ## Interoperability, Validation, and Testing BED's lack of a single formal specification is the root of most interoperability trouble. The Acidbio verification system was built specifically to test how bioinformatics software handles format edge cases, including unexpected inputs that sit at the limits of the specification. Testing 80 Bioconda packages that parsed BED found that 75 scored below 70 percent correctness, and automated fuzzing detected errors the manually designed suite missed [2]. The authors also built a badge system so developers can declare which BED variants their software actually accepts [2]. For an analyst, the practical testing protocol is a small set of round-trip checks that catch most problems before they reach a result. 1. **Column count check**: confirm every data line has the same number of fields. 2. **Coordinate sanity check**: confirm `chromStart` is less than or equal to `chromEnd` on every line, and that `chromEnd` does not exceed the chromosome length in the reference. 3. **Sort check**: confirm chromosome order and start order are monotonic. 4. **Naming check**: confirm the chromosome names match the reference and the comparison file exactly, including any `chr` prefix. 5. **Round-trip check**: convert a small test set to another format and back, then compare coordinates. Any one-base shift indicates a coordinate convention mismatch. 6. **Boundary check**: include an interval starting at position 0 and an interval ending at the last base of a chromosome, since these are the cases most likely to be mishandled. A file that passes all six checks is not guaranteed correct, but a file that fails any of them is guaranteed to produce unreliable output. ## Common Mistakes and Limitations **Treating BED as one-based.** This is the most common and most damaging error. A BED start of 1000 means the feature begins at one-based base 1001. Copying coordinates from a GFF, a VCF, or a paper's one-based notation without subtracting one shifts every feature. The file still parses, so nothing announces the mistake. **Mixing coordinate systems within a pipeline.** If one step reads BED and internally converts to one-based coordinates, and a later step assumes the original BED values, the shift compounds. Document the convention at each step or keep everything in BED until the final output. **Ignoring the sort requirement.** Many interval operations assume sorted input. Unsorted input can produce merged intervals that should not have merged, or intersections that silently miss. Sort before every operation that requires it, and do not assume a previous step sorted the file. **Assuming chromosome naming is consistent.** `chr1` and `1` are different strings. `chrM` and `chrMT` are different strings. A zero-overlap result usually means a naming mismatch, not a biological absence. **Assuming every BED has 12 columns.** Column count is the variant definition. A BED3 file parsed as BED12 will read garbage into the name, score, and strand fields, or fail outright. Check the first data line. **Forgetting the `track` and `browser` header lines.** BED files prepared for browser display may begin with `track` or `browser` lines, and may contain `#` comments. Some parsers skip these gracefully. Others treat them as data. The variability is a direct consequence of the format's informal specification [2]. **Using zero-length intervals casually.** Some tools use `chromStart` equal to `chromEnd` to mark an insertion point. Not all parsers handle that case consistently, and it is exactly the kind of edge case that validation suites are designed to catch [2]. **Storing pounds of data as text.** A BED file with tens of millions of intervals is slow to parse and expensive to ship. Convert to bigBed for browser access, or bgzip and tabix-index for command-line access. **Expecting BED to carry biology.** A BED interval has no inherent meaning. Whether a region is a promoter, an enhancer, or an artifact depends on the experiment that produced it. The format is a container, and containers do not validate their contents. **Confusing BED's score column with a statistical measure.** The score field is conventionally 0 to 1000 and is primarily for display. Pipelines that repurpose it for p-values or quality scores create files that look standard but are not comparable across sources. ## Quick Review 1. BED is a tab-delimited interval format with three required columns (`chrom`, `chromStart`, `chromEnd`) and up to nine optional columns. 2. BED coordinates are zero-based and half-open, so the interval length is always `chromEnd - chromStart`. 3. Converting from GFF/GTF requires subtracting one from the start only, never from the end. 4. BED3, BED6, BED12, bedGraph, and BEDPE are distinct variants, and column count defines which one you have. 5. Interval operations require sorted input and consistent chromosome naming across all files. 6. BED stores coordinates, not sequence and not variants. FASTA and FASTQ store sequence, and VCF stores alleles. 7. Interoperability is not guaranteed. Validate column counts, coordinate order, and round-trip conversions before trusting output [2]. ## Frequently Asked Questions ### What does BED file mean in bioinformatics? A BED file is a plain-text table of genomic intervals, with each line giving a chromosome, a zero-based start, and a half-open end. The name stands for Browser Extensible Data, reflecting its origin as a UCSC Genome Browser annotation format. ### Is BED zero-based or one-based? BED is zero-based for the start coordinate and half-open for the end. The first base of a chromosome is 0, and the end coordinate points one base past the last base of the feature. ### What is the difference between BED3, BED6, and BED12? BED3 has only coordinates. BED6 adds name, score, and strand. BED12 adds thick start, thick end, item color, block count, block sizes, and block starts, which is what allows a multi-exon feature to be drawn. ### Can a BED file store DNA sequence? No. BED stores coordinates only. To get the bases under your intervals, use `bedtools getfasta` with a reference FASTA, which writes the extracted sequences to a new FASTA file. ### Why do my BED intersections return zero intervals? The usual causes are a chromosome naming mismatch such as `chr1` versus `1`, a reference assembly mismatch such as hg19 versus hg38, or an unsorted input file. Check naming and sorting first, since neither problem produces an error message. ### What is the difference between a BED file and a VCF file? BED describes regions and VCF describes variants. A VCF record carries alleles and genotypes, while a BED record carries only a span. Converting VCF to BED keeps the positions and discards all the biological content. ## Sources 1. [Overview of Sequence Data Formats.](https://pubmed.ncbi.nlm.nih.gov/27008007/) 2. [Assessing and assuring interoperability of a genomics file format.](https://pubmed.ncbi.nlm.nih.gov/35575355/) 3. [The proBAM and proBed standard formats: enabling a seamless integration of genomics and proteomics data.](https://pubmed.ncbi.nlm.nih.gov/29386051/) 4. [ChoCallate: a computational pipeline for consensus germline variant calling in genomic sequencing data.](https://pubmed.ncbi.nlm.nih.gov/42828029/) 5. [Bamgineer: Introduction of simulated allele-specific copy number variants into exome and targeted sequence data sets.](https://pubmed.ncbi.nlm.nih.gov/29590101/) 6. [Semiconductor sequencing: how many flows do you need?](https://pubmed.ncbi.nlm.nih.gov/25480372/) 7. [EXONSAMPLER: a computer program for genome-wide and candidate gene exon sampling for targeted next-generation sequencing.](https://pubmed.ncbi.nlm.nih.gov/24751285/) 8. [Automated computational analysis of genome-wide DNA methylation profiling data from HELP-tagging assays.](https://pubmed.ncbi.nlm.nih.gov/22130985/) 9. [wgbstools: a computational suite for DNA methylation sequencing data analysis.](https://pubmed.ncbi.nlm.nih.gov/41611450/) 10. [Pattern-based Search of Epigenomic Data Using GeNemo.](https://pubmed.ncbi.nlm.nih.gov/29053670/) 11. [CGDV: a webtool for circular visualization of genomics and transcriptomics data.](https://pubmed.ncbi.nlm.nih.gov/29065857/) 12. [Streamline Protocol for Bulk-RNA Sequencing: From Data Extraction to Expression Analysis.](https://pubmed.ncbi.nlm.nih.gov/41637157/) 13. [IGD: a simple, efficient genotype data format.](https://pubmed.ncbi.nlm.nih.gov/40980555/) 14. [QCatch: a framework for quality control assessment and analysis of single-cell sequencing data.](https://pubmed.ncbi.nlm.nih.gov/41987571/) 15. [OME-Zarr: a cloud-optimized bioimaging file format with international community support.](https://pubmed.ncbi.nlm.nih.gov/37428210/) 16. [The enduring advantages of the SLOW5 file format for raw nanopore sequencing data.](https://pubmed.ncbi.nlm.nih.gov/41100284/)