Converting repeating decimals to fractions sounds like high-school math, but it comes up in the wild more often than people expect. I spent a stretch working in actuarial data cleanup where we'd get ratios from legacy systems as decimals and needed them as exact fractions for downstream work. The method itself is two lines of algebra, but the edge cases eat people alive.
How To Change Repeating Decimals Into Fractions
Write the repeating decimal equal to x. Multiply both sides by a power of 10 that shifts the decimal point past one full repeating block. Subtract the original equation from that new equation. The repeating tail cancels out. Divide by the coefficient on the left and simplify the fraction if it reduces. Here is the basic version with a clean single-digit repeat. x = 0.2222...
10x = 2.2222... Subtracting gives 10x x = 2.2222... 0.2222..., so 9x = 2. Then x = 2/9. Now a two-digit repeat, which is where most people trip up because they still multiply by 10 instead of 100.
x = 0.454545... 100x = 45.454545... Subtracting gives 99x = 45. x = 45/99, which simplifies to 5/11.
Get the Full Details
The shortcut for the denominator is basically a string of 9s equal to the length of the repeating block. One digit repeats, use 9. Two digits repeat, use 99. Three digits repeat, use 999. If the repeat starts right after the decimal point, you divide the repeating block by that string of 9s and simplify. That shortcut only works when the repeat begins immediately. Once you have a non-repeating prefix, you multiply by a higher power of 10 to shift past both the prefix and one repeating cycle, then subtract the equation that only shifts past the prefix. It is easier to see than to describe abstractly. x = 0.1666...
10x = 1.666... 100x = 16.666... Subtracting the first shifted equation from the second: 100x 10x = 15, so 90x = 15. x = 15/90 = 1/6.
I learned the hard way that skipping the prefix step produces wrong denominators every time. People default to 99 because they count digits without paying attention to position, and then they wonder why 1/6 turns into 5/33 in their notes. Here is a longer example that shows the pattern scaling. x = 0.138138138...
1000x = 138.138138... Subtracting gives 999x = 138. x = 138/999. Both are divisible by 3, so x = 46/333. That does not simplify further. The denominator comes from 999 because the repeat is three digits. The numerator is just the repeating block. That rule holds for any pure repeating decimal, which is a useful check while you are doing this by hand.
Mixed repeats follow the same subtraction logic, but the denominator has an extra factor of 10 for each non-repeating digit before the bar. x = 0.0272727... 10x = 0.272727...
1000x = 27.272727... Subtracting: 1000x 10x = 27, so 990x = 27. x = 27/990 = 3/110. You can verify quickly by dividing 3 by 110. The result is 0.027 with 27 repeating, which matches.
I ran into a problem last year that made me appreciate how fragile this gets by hand. I had a legacy financial file that listed a rate as 0.142857142857 and asked me to convert it. That is 1/7 written out, but without knowing that going in, the raw fraction is 142857/999999. Simplifying that requires finding the GCD of 142857 and 999999. The GCD is 142857, which gives 1/7, but getting there without a calculator is tedious. I wrote a small script that computes the numerator from the repeating block, the denominator from a string of 9s, then runs Euclid's algorithm to reduce it. That cut the time per value from about two minutes of manual work to under three seconds and eliminated the occasional arithmetic slips I was making on the long ones. That example also highlights a practical limit. The longer the repeating block, the more unwieldy the unsimplified fraction becomes. A six-digit repeat uses 999999 as the denominator, and a nine-digit repeat uses 999999999. You can still do these by hand if you are comfortable with GCD reduction, but the probability of error climbs fast once the block reaches five or more digits. In those cases, either use a tool or keep the fraction unsimplified until the final step where you reduce. Another thing people miss is that not every repeating decimal produces a simple fraction. Some repeats give denominators with large prime factors that do not reduce nicely, and that is normal. For example, x = 0.148148148... gives 148/999, which reduces to 4/27 because the GCD is 37. If you try to simplify by eye and only check small primes, you will leave 148/999 on the page and wonder why later calculations are off.
There is also a boundary condition worth stating plainly. The algebraic method assumes an infinite repeating decimal. If you are given a finite decimal that someone labeled with a bar because it was rounded from a longer expansion, the method will produce an approximate fraction, not the exact original ratio. In practice, this showed up when I was reverse-engineering tolerance ratios from scanned engineering tables. The printed values were rounded to six decimal places, but the bar notation implied exact repetition. I had to round the decimal to the nearest simple fraction first, using continued fractions, before the repeating-decimal method would give a result that matched the intended physical ratio. If you want a faster path for mixed repeats without writing out multiple equations, you can separate the terminating and repeating parts and add them. 0.1666... = 0.1 + 0.0666...
0.1 = 1/10. 0.0666... = 0.6/9 = 6/90 = 1/15. 1/10 + 1/15 = 3/30 + 2/30 = 5/30 = 1/6.
That works, but it is essentially the same algebra in disguise. It feels shorter only when the numbers are small. One more nuance. Some repeating decimals convert to very clean fractions because the denominator factors into small primes. Others do not, and the denominator can be large even when the fraction is fully reduced. There is no shortcut around that except accepting the result as-is or using a computational tool. If you are doing this regularly, a lightweight helper is worth building. A short function that takes the decimal string, identifies whether the repeat starts immediately or after a prefix, builds the numerator and denominator from the appropriate 9s and 0s, then applies GCD reduction will handle the routine cases in under a second. For long repeats or batch processing, I switched to continued-fraction convergence to find the best low-denominator rational approximation when exact conversion was producing unwieldy fractions that the downstream system could not handle.
The method is reliable, but it is not magic. Long repeating blocks, mixed repeats with large prefixes, and rounded inputs are where it breaks down in practice. Know the limits, double-check your GCD steps, and stop pretending every repeating decimal collapses into a neat little fraction you can write on a sticky note.
