Introduction

The standard way to convert a string to a double in Java is Double.parseDouble(...). It is fast, simple, and correct for normal Java-style numeric text such as "3.14" or "1e6".

The real challenge is not the conversion itself. It is deciding what should happen when the input is invalid, locale-specific, or too precise for binary floating-point.

The Normal Case: Double.parseDouble

This is the basic approach:

1public class ParseDoubleExample {
2    public static void main(String[] args) {
3        String text = "23.456";
4        double value = Double.parseDouble(text);
5        System.out.println(value);
6    }
7}

If the string is not a valid representation of a double, Java throws NumberFormatException.

So for user input or external data, wrap it:

1public class SafeParse {
2    public static void main(String[] args) {
3        String text = "abc";
4
5        try {
6            double value = Double.parseDouble(text);
7            System.out.println(value);
8        } catch (NumberFormatException ex) {
9            System.out.println("Not a valid double: " + text);
10        }
11    }
12}

parseDouble Versus valueOf

Double.valueOf(...) is closely related:

Double boxed = Double.valueOf("12.5");
double primitive = Double.parseDouble("12.5");

Use parseDouble when you want a primitive double. Use valueOf when you specifically need a Double object.

For most everyday code, parseDouble is the more direct choice.

Handle Whitespace and Validation Intentionally

If input comes from a file or user form, trimming it first is often reasonable:

String raw = "  42.0  ";
double value = Double.parseDouble(raw.trim());
System.out.println(value);

That said, do not guess too much. If the system requires strict formatting, validate and reject rather than silently normalizing everything.

Locale-Specific Numbers Need a Different Parser

Double.parseDouble expects Java's standard numeric format. It does not understand locale conventions such as "1,23" for one-point-two-three.

For locale-aware parsing, use NumberFormat:

1import java.text.NumberFormat;
2import java.text.ParseException;
3import java.util.Locale;
4
5public class LocaleParseExample {
6    public static void main(String[] args) throws ParseException {
7        NumberFormat format = NumberFormat.getInstance(Locale.GERMANY);
8        Number number = format.parse("1,23");
9        double value = number.doubleValue();
10        System.out.println(value);
11    }
12}

This is the right approach when the input format depends on a user's locale or on a known external format.

Beware of Floating-Point Precision

A double is a binary floating-point type. That means some decimal values cannot be represented exactly.

double value = Double.parseDouble("0.1");
System.out.println(value + value + value);

This is fine for many scientific and general-purpose calculations, but not ideal for exact financial arithmetic. If exact decimal precision matters, parse into BigDecimal instead:

1import java.math.BigDecimal;
2
3BigDecimal amount = new BigDecimal("123.45");
4System.out.println(amount);

That is not a double, but it is often the correct answer when people think they want one.

Special Values

Java accepts some special text values too:

System.out.println(Double.parseDouble("NaN"));
System.out.println(Double.parseDouble("Infinity"));

Those may be legitimate in some systems and dangerous in others. If your input should represent ordinary finite numbers only, validate after parsing:

1double value = Double.parseDouble(text);
2if (!Double.isFinite(value)) {
3    throw new IllegalArgumentException("Expected a finite number");
4}

Common Pitfalls

The biggest pitfall is assuming every numeric-looking string belongs in a double. Locale-specific input, money amounts, and IDs often need a different type or parser.

Another common mistake is swallowing NumberFormatException without explaining what was wrong with the input. Good error messages matter when data comes from users or external systems.

People also forget about precision. Converting to double is easy, but exact decimals may not survive the conversion the way you expect.

Finally, do not use locale-aware parsing accidentally when the format is supposed to be strict and machine-readable. Be explicit about which format the program accepts.

Summary

• Use Double.parseDouble(...) for normal Java-style numeric strings.
• Catch NumberFormatException when input is uncertain.
• Use NumberFormat for locale-specific formats such as comma decimals.
• Use BigDecimal when exact decimal precision matters.
• Validate special values such as NaN and Infinity if your domain does not allow them.