Why Your Calculator Keeps Giving You Wrong Answers
The formula is /180. Multiply your degree value by that fraction and you get radians. That's it. But in practice, people mess this up constantly because they either leave their calculator in degree mode when they shouldn't, or they forget that programming languages handle this differently than calculators do. I spent three weeks debugging a shader that was rendering completely wrong angles. Turns out the entire animation loop was passing degrees into a function that expected radians, and somewhere in the middle someone had thrown in a half-hearted conversion that was actually making things worse. The fix was rewriting the whole angle pipeline with explicit radian values. It took about two hours to trace and fix. I still don't know who wrote that broken conversion.
Converting Degrees To Radians in Practice
The mathematical definition is straightforward: one full rotation equals 360 degrees or 2 radians. So 1 degree equals 2/360, which simplifies to /180. When you're converting, you multiply the degree measure by /180. For example, 90 degrees times /180 gives you /2 radians. It's a linear scaling operation. There's nothing particularly deep about the math itself. Where things get messy is in the tools. Most programming languages have built-in functions for this. In JavaScript, you'd use rad = deg * Math.PI / 180 or call Math.radians if you're using a library that provides it. Python's math.degrees() goes the other direction, so math.radians() is what you want. In C and C++, you'll typically write a small helper function since the standard library doesn't include a dedicated radian converter in most versions before C++17, and even then support is spotty across compilers. Here's something most beginners don't catch: trigonometric functions in virtually every language and library expect radians, not degrees. This is the single most common source of errors I see. sin(90) in most programming contexts does not equal 1. It equals approximately 0.894. The function is treating 90 as radians, which is roughly 5156 degrees. If you want sin(90°), you need to convert first: sin(90 * /180) = sin(/2) = 1. Get this wrong and your graphics code, physics simulations, and game development will all produce output that looks subtly broken in ways that are incredibly hard to debug because the numbers are technically valid, just applied to the wrong scale.
I ran into a particularly nasty edge case with floating point precision when working with very large angle values. Someone was converting angles measured in degrees that had accumulated over thousands of simulation steps. A value like 45678.123456 degrees would convert to radians and lose precision through the multiplication, then feeding that into sin() or cos() would produce garbage results because the trig functions themselves aren't designed to handle arguments that large with meaningful precision. The workaround was to normalize the angle to a 0-360 range using modulo arithmetic before converting to radians. (45678.123456 % 360) * Math.PI / 180 gives you the equivalent angle in the standard range, and the trig functions handle that with full floating point accuracy. Another thing worth knowing: in many graphics APIs and game engines, there's a constant for /2, /4, and sometimes even a full tab of common radian values. Using these constants instead of writing out the conversions repeatedly reduces both the chance of error and the cognitive load when reading code. Instead of multiplying by Math.PI/180 every time you need 30 degrees, you just reference a constant or use a named enum value. This is especially relevant in performance-critical code where the conversion happens every frame. One more practical note: Excel handles this fine with the RADIANS() function, which is almost too convenient. People get used to it and then forget how to do the manual conversion when they step outside of spreadsheets. The manual method is still just multiply by and divide by 180. On a calculator, you can also set it to radian mode and skip the conversion entirely, but this breaks everything else that needs degrees. You'll end up switching modes back and forth and occasionally forget, which is basically the same failure mode as the programming problem described above, just slower to debug since you're doing it by hand.
Get the Full Details
If you're doing a lot of angle work, consider whether your workflow actually needs radians or whether you can stay in degrees the whole time and only convert at the boundaries. Some CAD tools and older game engines work primarily in degrees internally and only convert when calling into external libraries that require radians. Mixing these conventions across a codebase is one of the fastest ways to introduce subtle bugs that only appear under specific conditions. Document your convention clearly and make it a point of review in code audits. It saves weeks of debugging down the line.
