PLINK Genotype Files and Conversion Checks

Why Check a Conversion?

A genotype file can be syntactically valid and still represent the wrong analysis data. A sample-order mismatch can attach one person's genotypes to another person's record; an allele-label mismatch can reverse the meaning of a genotype count; and a conversion can omit or recode variants. Checking the files after conversion is therefore part of preparing genetic data, not merely a file-management task.

A common PLINK 1 binary data set is a trio of files with the same base name: .bed, .bim, and .fam. The BED file stores genotype calls in binary form. BIM and FAM are text files that provide the variant and sample information needed to interpret those calls. In a VCF, by contrast, variant records and sample genotypes are presented together in one text-based file. The formats organize related information differently, so comparisons must check both the labels and the order.

What the Three PLINK Files Contain

The .bed file is binary, not a table of readable genotype labels. In the standard PLINK 1 SNP-major layout, a short header identifies the file format and storage mode, followed by two bits per sample-variant genotype. Four genotypes fit in one byte; if the number of samples is not divisible by four, the final byte for a variant includes unused padding bits. The bits are codes, not allele letters. To interpret a call, software uses the corresponding variant's allele labels in BIM.

The .bim file is a tab-delimited text file with six columns, in this order: chromosome, variant ID, genetic distance in centimorgans, base-pair position, allele 1 (A1), and allele 2 (A2). A1 and A2 name the two alleles represented for that variant in the PLINK data. They do not, by themselves, tell you which allele is the reference allele, the alternate allele, or an effect allele. A1/A2 ordering can differ from the REF/ALT ordering in a VCF.

The .fam file has one row per sample, with six fields: family ID (FID), individual ID (IID), father ID, mother ID, sex, and phenotype. Sex is commonly coded 1 for male, 2 for female, and 0 for unknown. A binary phenotype is commonly coded 1 for control and 2 for case; a missing phenotype is often represented by -9. These fields describe sample records, while the genotype data for those samples are stored in BED. If the analysis does not use pedigree or phenotype information, those FAM fields still need to be retained or handled deliberately.

The BED header also indicates its storage mode. Standard PLINK 1 binary files use SNP-major storage: successive genotype blocks correspond to successive variants. PLINK supports other storage modes in some contexts, so checks should confirm that the file was written and read as intended rather than assuming that any binary file can be interpreted from its byte sequence alone. In ordinary use, PLINK reads BED together with its matching BIM and FAM files.

How This Differs From a VCF

A VCF has variant records in rows. Each record includes fields such as chromosome, position, ID, REF, ALT, and FORMAT; sample genotype fields follow in columns whose order is given in the VCF header. For a biallelic variant, a GT value such as 0/1 refers to the allele indices in that record: 0 denotes REF and 1 denotes ALT. Thus, 0/1 describes one copy of each listed allele, not a fixed PLINK genotype code.

PLINK separates this information across files. BIM supplies the variant identifiers, positions, and allele labels; FAM supplies sample identifiers; BED supplies calls in the two files' corresponding order. The same biological genotype can therefore have different labels or codes in the two formats. For example, a VCF may list REF=A and ALT=G, while the PLINK BIM line lists A1=G and A2=A. Those labels are not inconsistent if the genotype calls correspond after accounting for the allele order.

Worked Checks After Conversion

A useful validation has several layers. First compare file dimensions and identifiers. Then compare variant locations and allele labels, allowing for an intentional allele-order difference. Finally compare calls for matched samples and variants, translating both formats into allele pairs. A few hand-checked calls can catch errors quickly; a full automated comparison is preferable when the data set is large.

A Practical Conversion-Check Sequence

Why the Details Matter

A PLINK binary genotype is a compact representation of a diploid call, not a complete copy of all information in a VCF. For example, a VCF can contain genotype quality, read depth, phasing, or likelihood fields alongside GT. The BED/BIM/FAM trio does not preserve all such fields. A conversion may also need a specific choice for how to handle multiallelic sites, missing data, or dosage values. Record the conversion settings and check what was retained, rather than concluding that the files match because they open successfully.

A concise validation report should state the input and output sample and variant counts, how identifiers were matched, whether order was preserved or changed, how allele labels were reconciled, and how many calls were compared or differed. When checking calls programmatically, compare matched sample-variant pairs after translating allele labels; a raw comparison of GT strings and internal PLINK codes is not meaningful.

These checks focus on whether records and calls were transferred consistently. Allele labels alone do not establish strand orientation or biological reference status; those require separate scrutiny. The essential habit is to treat sample order, variant order, and allele coding as explicit parts of the data, rather than assuming that a successful file conversion guarantees their preservation.