Introduction

Counting the digits in a ulong sounds simple, but good code still needs to handle zero correctly and avoid unnecessary complexity. In C#, the most dependable answer is usually repeated division by ten. Other approaches such as logarithms or string conversion can work too, but they trade off precision assumptions, allocations, or readability in different ways.

The Most Reliable Method: Divide by Ten

The classic integer-only approach repeatedly divides the value by 10 until nothing is left.

1using System;
2
3public static class DigitTools
4{
5    public static int CountDigits(ulong value)
6    {
7        if (value == 0)
8            return 1;
9
10        int digits = 0;
11        while (value > 0)
12        {
13            value /= 10;
14            digits++;
15        }
16
17        return digits;
18    }
19}
20
21Console.WriteLine(DigitTools.CountDigits(0));
22Console.WriteLine(DigitTools.CountDigits(9));
23Console.WriteLine(DigitTools.CountDigits(10));
24Console.WriteLine(DigitTools.CountDigits(ulong.MaxValue));

This is usually the best default because it is precise for the full ulong range and easy to trust.

String Length Is the Simplest to Read

If raw performance is not important, converting to string is often the clearest option.

1using System;
2
3public static int CountDigitsByString(ulong value)
4{
5    return value.ToString().Length;
6}
7
8Console.WriteLine(CountDigitsByString(1234567890UL));

This is easy to understand, but it allocates a string, so it is not ideal inside a hot numeric loop.

The Logarithm Shortcut

Another compact formula is floor(log10(n)) + 1.

1using System;
2
3public static int CountDigitsByLog(ulong value)
4{
5    if (value == 0)
6        return 1;
7
8    return (int)Math.Floor(Math.Log10(value)) + 1;
9}

This works in most everyday cases, but some teams still prefer the division method because it stays entirely in integer arithmetic and avoids any floating-point edge-case concern.

Fast Range Checks for Fixed ulong

If you are optimizing a very hot path and know the type is always ulong, a branch table can avoid the loop.

1public static int CountDigitsByRanges(ulong n)
2{
3    if (n < 10UL) return 1;
4    if (n < 100UL) return 2;
5    if (n < 1_000UL) return 3;
6    if (n < 10_000UL) return 4;
7    if (n < 100_000UL) return 5;
8    if (n < 1_000_000UL) return 6;
9    if (n < 10_000_000UL) return 7;
10    if (n < 100_000_000UL) return 8;
11    if (n < 1_000_000_000UL) return 9;
12    if (n < 10_000_000_000UL) return 10;
13    if (n < 100_000_000_000UL) return 11;
14    if (n < 1_000_000_000_000UL) return 12;
15    if (n < 10_000_000_000_000UL) return 13;
16    if (n < 100_000_000_000_000UL) return 14;
17    if (n < 1_000_000_000_000_000UL) return 15;
18    if (n < 10_000_000_000_000_000UL) return 16;
19    if (n < 100_000_000_000_000_000UL) return 17;
20    if (n < 1_000_000_000_000_000_000UL) return 18;
21    if (n < 10_000_000_000_000_000_000UL) return 19;
22    return 20;
23}

This is fast but much less maintainable than the loop.

Boundary Tests Matter Most

Off-by-one bugs usually show up at powers of ten.

1using System;
2
3ulong[] cases =
4{
5    0UL,
6    1UL,
7    9UL,
8    10UL,
9    99UL,
10    100UL,
11    999UL,
12    1000UL,
13    ulong.MaxValue
14};
15
16foreach (ulong n in cases)
17{
18    int digits = DigitTools.CountDigits(n);
19    Console.WriteLine($"{n} -> {digits}");
20}

If you change implementations later, keep a simple reference version and compare against it in tests.

Common Pitfalls

• Forgetting that zero has one digit, not zero digits.
• Using the logarithm formula without a special-case branch for zero.
• Choosing string conversion inside a performance-critical loop without measuring the cost.
• Optimizing with a branch table before proving that digit counting is actually a bottleneck.
• Failing to test values at boundaries such as 9, 10, 99, and 100.

Summary

• Repeated division by ten is the most robust general solution for ulong digit counting.
• 'ToString().Length is often the easiest to read when performance is not critical.'
• Logarithm-based formulas are compact but rely on floating-point math.
• Range checks can be fast for fixed-size integer types, but they are less maintainable.
• Always test boundary values and handle zero explicitly.