200+ unit converters in Area, Length, Mass, Speed, Temperature, and Time categories;
Precision: up to 28 decimal places;
Conversion formulas with examples;
Neat UI with light/dark theme.
The website shares cookies with Google over Google Analytics only if cookies are accepted via consent banner, otherwise the website browsing is completely anonymous. Regarding 1496 partners, these entities will not get any information if there is no services associated with them plugged-in to our website (and there is no such in our case). They are just registered partners of Cookie Consent Provider that we use on our website.
Our service uses backend to perform high-precision calculations not available through Javascript. That’s why it was an intentional decision in order to avoid any delays between entering the text and backend response. However, we might change our decision after additional performance testing.
Has the same problem with time as I see elsewhere. I don't don't want to convert a billion seconds to number of hours and then days and then weeks and months and then years. I want to translate that to a human readable years/months/days/hours/minutes/seconds in one click.
The red under "Free Online" looks weird to my eyes, like it was half crossed out with a red highlighter.
The helpful descriptions under the conversion doesn't seem to switch to the ones you have selected. I expected when I switched the time from minutes to years, the box would have defined years.
Usually users search a specific unit conversion, such as “convert meters to feet”. They will be redirected by a search engine to a dedicated page with detailed units descriptions down below the category page, example https://www.betaconvert.com/length/meters/feet , do their conversion and leave. For the case when a user begins navigation from top-bottom, we will consider to load a proper unit description on unit change as you have suggested.
I'm generally content with ddg converter, the only its issue it is hard to convert pounds into a metric units, because ddg stubbornly believes that the pound is a currency. It will happily convert pounds into dollars, but not into kilograms.
Hi - do you have an example query showing this issue? I just tried "45 lb to kg" on DuckDuckGo and it's working as I would expect (45 Pounds = 20.41166 Kilograms).
I would use "45 pounds", it really doesn't matter for me will ddg convert them into grams or kilograms or metric tons, I can read any of them.
But I tried "45 lb", and it works as the pound. I hadn't thought that "lb" is the pound. I mean I saw this abbreviation, and probably converted it into metric units, but didn't notice that "lb" == "pound". Seems like a crazy way to abbreviate.
I find natural language much easier, it's one single interface-- I just use raycast. If I type "20ft" it defaults showing in meters, so I don't even have to type anything extra, it's great
Having a dedicated page for a category or particular conversion between units, allows adding extra information, such as info about unit of measurement and formula. Example: https://www.betaconvert.com/length/meters/feet
We use high-precision calculations up to 28 decimal digits that cannot be provided by numeric types available in Javascript. That’s why we do our calculations on the backend.
One way around this might be to test and see if you can do it via WebAssembly that the JS calls, just not sure off the too of my head how I would personally do it.
As others noted though, thats a lot of precision that maybe not everyone needs, maybe a checkbox for more precision that then calls the backend?
I'm finding it hard to buy that a precision of 28 decimal digits cannot be computed on today's browsers.
Why could you not have used one of the bigfloat[1] JavaScript libraries that exists? Is there an operation the service requires which is not supported by them?
In any case, thank you for the free service. I'm sure this will be useful to a lot of people. While I would not use a cloud-based calculator, I'm sure a lot of laypeople don't care how it's done, and I appreciate your focus on utmost accuracy.
We use C# “decimal” type on backend for high-precision calculations. Frankly, we do not trust third-party libraries when it comes to mission critical calculations. We would better stay safe with well-tested enterprise frameworks like .NET.
Although I was a little, um, assertive in some of my comments here, I honestly mean them constructively, in the spirit of "here are some things you might consider to make it more useful". I apologize for missing the joke.
I can't think of an example of a real-life measurement with 28 decimal digits of precision, and if there is, I bet they have a custom converter.
Please don't be the calculator that ignores significant digits and encourages people to write nonsense things like "an adult blue whale can be up to 29.9 meters (1177.16535 inches) long".
> Think about that. We have a circle more than 94 billion miles (more than 150 billion kilometers) around, and our calculation of that distance would be off by no more than the width of your little finger.
Anyone who needs more precision than that is almost certainly sitting next to a computer with bespoke software running on it.
Which is cool and all, but totally unnecessary for approximately 100% of users. You should at least provide an option to do everything in js.
Also, for ux reasons, I'd love this as a browser extension. Cloudy Calculator can do a lot of it but was recently deprecated as a result of the Manifest v2->v3 requirement from Google.
When a user converts, for example, 0.0001 millimeters to miles, most of converters out there will fail to provide the correct result due to precision loss. I know, it’s rare case, but we want to ensure that we can handle all cases without exception.
Your site doesn't work by that standard. English<=>metric distance eventually comes down to how accurately you can represent 1/127 (because 1in==25.4mm). 1/127 repeats after 42 digits and you only support 28.
You can't give exact answers without representing everything as fractions, even for the easy ones like mm to miles. With that being true, anything more than JavaScript's own precision is probably unhelpful.
The kind of person solving problems where they'd need to convert between miles and mm would rewrite the constant as "1mi = 1,609,344mm". No one in the real world is adding up 0.0001mm intervals until they get to a mile, so you're solving for a problem that doesn't actually exist.
reply