Bookmakers publish the same price in three incompatible notations. Decimal dominates in Europe and Australia, fractional persists in UK horse racing, and American (moneyline) is standard in the United States. They encode identical information; only the arithmetic differs.
The conversions
- Decimal → implied probability:
p = 1 / d - Fractional → decimal:
d = (numerator / denominator) + 1 - American positive → decimal:
d = (odds / 100) + 1 - American negative → decimal:
d = (100 / |odds|) + 1
Worked example
A price of 2.50 decimal is 3/2 fractional and +150 American. Each says the same thing: stake 2 to win 3, for a total return of 5. The implied probability is 1 / 2.50 = 40%. A price of 1.50 decimal is 1/2 fractional and −200 American, implying 66.7%.
The trap most people hit
Fractional odds quote profit, decimal odds quote total return. 3/2 and 2.50 look unrelated until you notice the decimal figure includes your stake back. This is the single most common source of off-by-one-stake errors when porting a betting model between markets.
Doing this at scale
Converting one price by hand is arithmetic. Converting every price for every fixture is a data problem: you need fixtures, teams and stable identifiers to attach prices to. Stats API supplies the fixture and team layer with identifiers that do not change between requests, so your odds pipeline has something durable to key against.
Common questions
Which odds format should an API return?
Decimal. It converts to probability with a single division, has no sign convention to handle, and avoids the fraction-reduction ambiguity where 10/4 and 5/2 are the same price written two ways.
Why does +150 not equal −150?
American odds are asymmetric by design. A positive number is the profit on a 100 stake; a negative number is the stake required to profit 100. +150 implies 40%, −150 implies 60%.