Last updated: September 2026
Ask an AI to convert 250 pound-force-feet of torque to newton-metres and it will answer instantly, confidently, and sometimes wrong. Unit conversion looks like the safest thing you could ask a model to do, which is exactly why it is dangerous: the answer is a plausible number in the right ballpark, so it slides past a quick check and into a calculation. This guide covers why AI gets engineering unit conversions wrong, which conversions invite which mistakes, and a short workflow that keeps the error out of your work.
The failure has a specific cause, covered in our piece on why ChatGPT gets units wrong, and it sits inside the wider pattern of AI hallucination in engineering. If you want to measure how badly a given tool handles this, see how to run an AI calculation accuracy test. This article is the conversion-specific piece, and it sits under our hub on the best AI tools for engineers.
The short version: AI models get engineering unit conversions wrong because they represent numbers digit by digit and predict likely text rather than running a dimensional-analysis engine, so they pattern-match a conversion factor that is often close-but-wrong or applied in the wrong direction. The safe fix is to keep the model out of the arithmetic: state the units and the physical quantity explicitly, make it show the factor and direction, offload the math to a calculator or code, verify the factor against a standard such as NIST SP 811, and sanity-check the magnitude. Treat every AI conversion as a draft to check, not a result to trust.
Why AI gets unit conversions wrong
The root cause is architectural. A language model predicts the next likely token; it does not execute arithmetic or run a dimensional-analysis engine. Research shows that models represent numbers digit by digit in base 10 rather than as whole values, which is why their numeric errors tend to be spread across the digits of an answer rather than clustered near the right magnitude ([Levy and Geva](https://arxiv.org/abs/2410.11781), 2024). A study built specifically around numeral and measurement conversions found that models still struggle with exactly this task, especially once the phrasing is perturbed ([NUMCoT](https://arxiv.org/abs/2406.02864), 2024). Put those together and a conversion is close to a worst case: the model has to recall a precise factor, apply it in the correct direction, and keep the physical quantity straight, all by pattern-matching text rather than calculating.
The conversions that trip AI up
Some conversions invite specific mistakes. The factors below are the correct, standard values from NIST SP 811 and definitional constants; the last column illustrates the failure modes these conversions tend to produce, not a transcript of any particular model. Use it as a checklist of what to watch for.
| Conversion | Correct factor (verify) | Typical slip to watch for |
|---|---|---|
| inch to millimetre | 1 in = 25.4 mm (exact) | Truncated factor (uses 25 or 25.3), or inverts and divides by 25.4 |
| pound-mass to kilogram | 1 lb = 0.45359237 kg (exact) | Confuses lb-mass with lbf; rounds to 0.45 or 0.5; wrong direction |
| psi to bar | 1 psi = 0.0689476 bar | Multiplies by 14.5 instead of dividing; drops precision on large pressures |
| psi to pascal | 1 psi = 6894.757 Pa | Off by a factor of 1000 (kPa vs Pa); rounds to 6900 |
| Celsius to Fahrenheit | F = C x 9/5 + 32 | Forgets the +32 offset, or applies the offset before scaling |
| newton-metre to pound-force-foot (torque) | 1 lbf-ft = 1.355818 N-m | Swaps torque with energy (joules), or inverts the factor |
| kilowatt to horsepower | 1 hp = 745.699 W, so 1 kW = 1.341 hp | Mixes hp variants (metric hp = 735.5 W vs mechanical 745.7 W) |
Why a wrong conversion looks right
The danger is not that AI conversions are wildly off; it is that they are plausibly off. Because the model encodes numbers per digit, a slip often changes one or two digits, so 339 becomes 331 or 393, not something obviously absurd. The value still lands in the right order of magnitude, still carries the right unit label, and still reads like a finished answer, which is precisely what gets it waved through. A truncated factor, an inverted direction, or a metric-versus-mechanical horsepower mix-up all produce numbers that pass a glance. That is why checking the factor and the magnitude, rather than the plausibility of the output, is the only reliable defence.
How to prevent unit-conversion errors
The fix is to keep the model out of the arithmetic and give yourself two independent checks. The same discipline underlies our broader argument for why you should stop using AI for the calculation itself and the question of whether AI can do engineering calculations at all. For conversions specifically, a five-step workflow catches almost everything:
- State the units and the quantity explicitly. Ask for “250 lbf-ft of torque to N-m”, not “250 to metric”, so the model cannot silently swap torque for energy or pound-mass for pound-force.
- Make it show the factor and direction separately. Require “1 lbf-ft = 1.355818 N-m, therefore multiply” before the number. Wrong-direction and truncated-factor errors surface here.
- Offload the arithmetic. Use a calculator, Wolfram Alpha, or a units-aware library such as Python’s pint; research on program-aided models shows offloading the computation beats having the model reason it out ([PAL](https://arxiv.org/abs/2211.10435), 2022).
- Verify the factor against a standard. Check it in NIST SP 811 Appendix B or the BIPM SI brochure. Definitional factors such as 1 in = 25.4 mm must match exactly.
- Sanity-check the magnitude. Does 250 lbf-ft land near 339 N-m, not 34 or 3390? An order-of-magnitude check catches the factor-of-1000 and inverted-factor slips that look plausible.
What getting units wrong actually costs
Units are not a rounding detail, and engineering has an expensive reminder. In 1999 NASA lost the Mars Climate Orbiter because one team’s software supplied a thruster value in pound-force-seconds while the navigation software expected newton-seconds, so the spacecraft flew a path built on readings about a fifth of their true value ([NASA JPL](https://www.jpl.nasa.gov/news/mars-climate-orbiter-team-finds-likely-cause-of-loss/), 1999). The mission cost was around 327 million dollars. That was a human systems-engineering failure, not an AI one, and the point is not that AI would have caused it; the point is that a unit mismatch that looks like a small factor can be catastrophic, and an AI that hands you a plausible-but-wrong conversion is introducing exactly that class of error into your work. The stakes are why the verification steps above are not optional.
Frequently asked questions
Why does AI get unit conversions wrong?
Because a language model predicts likely text rather than calculating. It represents numbers digit by digit and has no dimensional-analysis engine, so it pattern-matches a conversion factor that may be close but wrong, or applies it in the wrong direction. Research on how models encode numbers and on numeral and measurement conversion both point to this as a structural weakness, not an occasional glitch.
Can I trust AI for simple conversions like inches to millimetres?
Only if you verify. Simple conversions are where people drop their guard, and a truncated factor such as “1 inch is about 25.3 mm” is both wrong and easy to miss. The defined value is exactly 25.4 mm. For anything that feeds a design or a purchase, confirm the factor against a standard and sanity-check the result rather than trusting the model’s number.
What is the safest way to convert units with AI?
Keep the model out of the arithmetic. State the source unit, target unit, and physical quantity; make it show the factor and direction; then offload the actual calculation to a calculator, Wolfram Alpha, or a units-aware code library. Finish by checking the factor against NIST SP 811 and confirming the magnitude passes a physical smell test.
Which unit conversions are most error-prone?
Ones with an offset rather than a pure ratio (Celsius to Fahrenheit), ones where the same name hides different definitions (mechanical versus metric horsepower, pound-mass versus pound-force), and ones where torque and energy share units (newton-metres and joules). Direction errors and factor-of-1000 slips (kPa versus Pa) are also common because the result still looks plausible.
Sources
- Levy and Geva, Language Models Encode Numbers Using Digit Representations in Base 10, arXiv 2410.11781
- Xu et al., NUMCoT: Numerals and Units of Measurement in Chain-of-Thought Reasoning, arXiv 2406.02864
- Gao et al., PAL: Program-aided Language Models, arXiv 2211.10435
- Cobbe et al., Training Verifiers to Solve Math Word Problems (GSM8K), arXiv 2110.14168
- NASA JPL, Mars Climate Orbiter Team Finds Likely Cause of Loss
- NIST Special Publication 811, Guide for the Use of the SI (conversion factors)
Written by the CognitiveFuture editorial team. Conversion factors are the correct definitional or NIST SP 811 values; the failure-mode examples are illustrative of documented weaknesses, not logged outputs from any specific model, and we did not benchmark any tool ourselves. The Mars Climate Orbiter is cited only as an analogy for why unit mismatches matter, not as an AI error. Confirm any factor against a current standard before you rely on it. This is general information, not engineering advice.
Richard Johnson
Richard Johnson is an AI specialist at one of the world's largest technology companies, where he has spent the past three years helping organizations adopt AI. CognitiveFuture extends that work publicly: gathering the available evidence on each tool, from vendor documentation to independent reviews and user feedback, and cutting a crowded market down to the right choice for the job in front of you.
