GCD / LCM Calculator
How it works
The greatest common divisor comes from the Euclidean algorithm, and the least common multiple
from lcm(a, b) = a × b ÷ gcd(a, b) — both reduced pairwise across the whole list,
so gcd(a, b, c) is gcd(gcd(a, b), c), and the same for LCM. Anything
typed that isn't a plain positive whole number (stray words, negative signs, decimals) is
quietly ignored rather than rejected, so a trailing comma or a pasted label doesn't break the
result. The running LCM is tracked as a BigInt internally, because the
a × b product it is built from can briefly exceed what a JavaScript number
represents exactly, even when the final LCM would not — the result is only ever converted back
once it is confirmed to still fit exactly.
Frequently asked questions
What are GCD and LCM actually used for?
The greatest common divisor is what you divide a fraction's top and bottom by to simplify it — 18/24 reduces to 3/4 because 6 is their GCD. The least common multiple is the smallest interval two repeating things share — two events every 4 days and every 6 days both land on day 12, their LCM, which is the standard way scheduling and repeating-interval problems get solved.
Why does this work the same way for more than two numbers?
Both GCD and LCM reduce pairwise across a list — gcd(a, b, c) is gcd(gcd(a, b), c), and LCM works the same way. Each extra number is just one more two-number step, so entering 5 numbers instead of 2 does not change how the answer is found, only how many times the same step runs.
Why does this tool say some inputs are "too large to represent precisely" instead of just answering?
LCM is computed as (a × b) / gcd(a, b), and that product can be enormous even when the final answer would not be — the LCM of a handful of ordinary-looking numbers can briefly need a value past what a JavaScript number can hold exactly (2^53 − 1). This tool tracks that product exactly under the hood and refuses to hand back a rounded, silently wrong answer once it would no longer fit.