How iToolHub computes and checks conversions

Every converter here answers the same way a person with a pencil would, and shows you the steps. This page explains where the fixed values come from, what arithmetic runs behind the result, what the build refuses to publish, and which published standards each family of tools follows.

Where the fixed values come from

A conversion tool has two kinds of number in it. There is the value you type, which the tool works out on the spot, and there is the fixed value it works with: that ASCII code 65 is the letter A, that one inch is 25.4 millimetres, that a byte is eight bits. The second kind is where a converter site usually goes wrong, because those values get typed into a page by hand, once per page, and then drift.

On iToolHub they are not typed into pages at all. They live in a knowledge base that a program generates, and the pages read from it. The core file for number systems and character encoding holds 2,107 facts. A further 16 files, one for each tool family, hold 894 between them: 329 for units, 103 for text encodings, 97 for data formats, 96 for image formats, 68 for colour, 65 for numerals, 59 for the calculators and utilities, 9 for age calculator, 9 for discount calculator, 9 for json formatter, 9 for loan calculator, 9 for percentage calculator, 8 for the binary calculator, 8 for hours calculator, 8 for lorem ipsum generator, 8 for word counter.

Those counts are not typed into this page either. They are counted from the files themselves each time the site is built, so this paragraph cannot fall out of step with what it describes.

Each row records one fact about one thing: which entity it describes, which attribute, the value, the unit, and where the value came from. Most rows are marked computed, meaning a program derived them rather than a person transcribing them. The generation report for the core file records 74 numeric claims taken from earlier planning documents and re-derived from first principles to test them. None of the 74 disagreed.

In plain terms: the ASCII table on this site was calculated, not copied, and every page that mentions ASCII 65 reads the same row.

The arithmetic is exact, not floating point

Most software does arithmetic in floating point, which stores numbers as binary fractions. That is fine for many jobs and wrong for this one. Floating point cannot hold 0.1 exactly, and it runs out of whole numbers above roughly nine quadrillion. A converter built on it gives a wrong answer with the same confidence as a right one.

Number bases

Base conversion here runs on arbitrary-precision integers from start to finish. A binary string has no length limit that comes from the arithmetic: paste 200 digits and every one of them counts. Place values are raised as whole numbers, products are added as whole numbers, and division truncates the way long division does on paper. There is no rounding step anywhere on that path, so there is nothing to round wrongly.

The signed readings on the two's complement page work the same way. The width is chosen first, the unsigned value is read, and the sign is applied by subtracting a power of two — all in whole numbers.

Units

Unit conversion cannot use whole numbers alone, so it uses exact fractions instead. Every factor in the units knowledge base is stored as a pair of whole numbers, a numerator and a denominator. One inch is stored as 254 over 10, not as the decimal 25.4, because 25.4 is already an approximation the moment a computer writes it in binary. Standard atmosphere is stored as 101325 over 760. A conversion is one multiplication and one division of exact fractions, so it cannot drift.

Angles carry one extra piece: the power of pi. Storing degrees as pi over 180 rather than as a decimal keeps degrees-to-gradians exact, because the pi cancels and the answer is the fraction 10 over 9.

Rounding happens once, at the end, and only when it has to:

CaseWhat is printed
The exact value terminates in decimal The exact value, in full. 1 inch is 25.4 mm, not 25.400000
The exact value does not terminate Ten significant figures
TemperatureOne decimal place
Running and cycling paceMinutes and seconds

Characters and encodings

Character conversion is not arithmetic at all. It is a table lookup followed by a base conversion, and the table is the one in the knowledge base. Text is read as UTF-8. Codes 0 to 127 are ASCII and mean the same thing in both. Above 127 the two part company, which is why the pages that cross that line say which one they are using.

Files

The image and file tools do their work on the page you are looking at. An image is decoded into a canvas in your browser and re-encoded from it; a file you drop on an encoding page is read by the browser's own file reader. Nothing is sent to a server. One consequence is worth knowing: a browser will answer a request for a format it cannot write by handing back a PNG instead, with no error. Every encode here checks the bytes that came back against the format that was asked for, and reports a failure rather than giving you a PNG with the wrong file extension.

What the build refuses to publish

Six checks run over the rendered site before it can ship. Each one can stop a build.

CheckWhat it will not let through
Facts A number printed on a page that disagrees with the knowledge base, or with the same number on another page
Frame A heading that uses vocabulary the page is not about, so a hex page cannot drift into talking about octal
Links An internal link that goes somewhere the link plan does not have, or a missing link the plan requires
Titles A page title or description that does not match the plan character for character, or repeats another page's
Wording Marketing vocabulary and emoji. The list is fixed, and a match fails the build rather than raising a note
Structured data Invented star ratings, invented authors, invented dates, and any machine-readable claim that is not also visible on the page

On top of that, the conversion code carries an automated test suite. The unit tests read the units knowledge base directly and compare it with the code row by row, so a value that changes in one place and not the other fails the build instead of shipping.

In plain terms: the checks exist because the risk on a site like this is not one dramatic error. It is thirty pages quietly disagreeing with each other.

The standards these tools follow

Nothing here is a house convention. Each family of tools implements a published specification, and you can read every one of these:

What this does not claim

Being exact about the arithmetic is not the same as being right about everything, so here is the boundary.

  • A conversion factor that is defined by a standards body is exact here. A factor that is a measurement rather than a definition is only as good as the published measurement, and the source is named on the page that uses it.
  • Image conversion depends on your browser's own encoder. Two browsers can produce different bytes from the same picture at the same quality setting, and neither is wrong.
  • Lossy formats lose data. Converting a JPEG to PNG does not restore what the JPEG threw away, and the pages that can lose data say so.
  • Nothing on this site is advice. The tools convert values.

How to check a result

You do not have to take any of this on trust, which is the reason the working is on the page rather than in a file you cannot see. Every converter shows its steps: the digits, the place values, the products and the sum for a base conversion; the factor and the arithmetic for a unit conversion; the code and the character for an encoding. Follow the steps with a pencil and you should land on the same answer. If you do not, the page is wrong and you should tell the operator.

Who is responsible

The site is maintained by Suraj Giri. How pages are written, checked and corrected, and how AI tools are used in producing them, is set out in the editorial policy. Confirmed corrections are logged with their dates in the changelog.

The ASCII table and the guide to number system conversion set out the same methods at more length.