KmerKeys
K-mer search across reference genomes — exact and fuzzy.
You give KmerKeys a DNA sequence (or a genomic coordinate range) and it reports every place that sequence's k-mers occur in a reference genome — including near-matches that differ by one or two bases.
Three indices are currently served, all at k = 31:
| Index | What it is | Coordinate input |
|---|---|---|
grch38 |
Human reference assembly GRCh38 | Yes |
chm13 |
T2T (telomere-to-telomere) assembly of CHM13 | Yes |
gnomad_exomes_chrY |
gnomAD v4.1 variant windows, chromosome Y exomes only | No |
chrN-pos-ref-alt), so a match tells you which
known variant your sequence overlaps. Whole-genome gnomAD coverage is not yet served.
The input type is detected automatically. On the Tool tab you can click Example input: sequence or coordinate to load a working example straight into the search box.
GGCCGGGCGCGGTGGCTCACGCCTGTAATCCCAGCACTTTGGGAGGCC.
The sequence is split into every overlapping 31-mer and each is searched.
Multiple lines are joined together, lines of differing length are fine, and
FASTA-style header lines beginning with > (or ;) are
ignored — so k-mers continue across line breaks but not across a
> line.
chr1:10000-10200 (1-based,
inclusive). The sequence is read from the reference FASTA, then searched as above.
Only available for indices with a FASTA on disk (grch38,
chm13 — not gnomad_exomes_chrY).
The coordinate form is parsed strictly: a single range on
one line, digits only — no thousands separators, no strand
suffix, and no lists of ranges.
Max Hamming distance controls how many mismatched bases are
tolerated: 0 is exact, 1 and 2 also return
near-matches. Hamming distance counts substitutions only — insertions and
deletions are not considered, so every match has the same length as your query k-mer.
Higher distances are dramatically more expensive: a 31-mer has ~94 neighbours at
distance 1 and ~4,300 at distance 2.
contig:start-end:strand. Positions are 1-based in reading order.
For d≥1, mismatches are listed in brackets as
position:REF>ALT — e.g. (5:A>C) means the match
differs from your query at offset 5, where an A is replaced by a
C.
Paste this Alu fragment — the most abundant repeat in the human genome —
into the Tool tab against grch38:
GGCCGGGCGCGGTGGCTCACGCCTGTAATCCCAGCACTTTGGGAGGCC
Each of its 31-mers matches tens of thousands of genomic locations, peaking around
90,000 — the copy-count profile of a retrotransposon that has propagated to over a
million copies. For contrast,
GATTACAGATTACAGATTACAGATTACAGATTACAG returns nothing: an invented
repeat that does not occur in the genome.
K-mer-based representations of genomic sequences are common in genomic data analysis and are appealing in their conceptual simplicity. However, there remains enormous potential for k-mer-based indexing to become a standard way of representing large collections of genomic data in an efficiently searchable form — for downstream tasks like oligonucleotide design and for representing genomic variation.
KmerKeys implements a sequence annotation architecture in which k-mers are associated with arbitrary metadata — genomic coordinates, counts, pointers to datasets, and known variants — which is dynamic, extensible to new metadata fields, and able to ingest commonly used genomic data formats (FASTA/Q, VCF, BED).
Given a query sequence, the service returns the number and locations of all exact or approximate k-mer matches in the selected index. Approximate matches differ from the query by at most a user-specified number of substitutions. Typical queries complete in well under a millisecond, far exceeding other available means of obtaining the same information; queries over highly repetitive sequence take longer in proportion to the number of matches returned. This supports applications such as DNA primer and CRISPR/Cas9 target design through fast identification of potential off-target sites.
The indices are stored in compressed form on disk and designed to optimise query speed, using bloom filters for fast rejection, memory-mapped I/O, zero-copy deserialisation, and optional parallelism during index construction.
If you use KmerKeys in your work, please cite:
Pavlichin DS, Lee H, Greer SU, Grimes SM, Weissman T, Ji HP. KmerKeys: a web resource for searching indexed genome assemblies and variants. Nucleic Acids Research 2022;50(W1):W448–W453. doi:10.1093/nar/gkac266
Questions, bug reports, and feature requests are welcome: hojoon@stanford.edu