Convert between 37 currencies with the rate named, the product shown before rounding, and the rounding done to the currency's own ISO 4217 minor unit rather than to two places for everything
Initializing in your browser…
Convert between MP3, WAV, OGG, AAC, M4A and FLAC with a bitrate, sample rate, channel count and bit depth that all reach the encoder, and a panel that reports what was actually written.
Convert between Unix timestamps and dates in any of 400+ time zones, in seconds, milliseconds, microseconds or nanoseconds
Convert across 18 categories using exact defining factors, with the definition behind every number shown
The rates come from a feed and cannot be checked from inside a page. The arithmetic can be, so here it is against a fixed table: 1 USD is 0.80 EUR, 150 JPY, 0.376 BHD and 0.00001 BTC.
Typed
1,234.56 USD
What the tool does with it
read as 1234.56 the comma is a group separator, not a decimal point rate 0.8 published for 1 USD, dated 2026-09-04 product 987.648 before any rounding rounded to 2 places the ISO 4217 minor unit of the EUR rounding moved 0.002 shown as 987.65 converting back 1234.56 USD no loss: both currencies have two places The same 1 USD into four currencies, each to its own minor unit: EUR 0.80 2 places JPY 150 0 places, because the yen has no subunit BHD 0.376 3 places, because the dinar divides into 1,000 fils BTC 0.00001000 8 places, a convention: BTC is not in ISO 4217
Three things here are the tool's own work rather than the feed's. The amount is read with a stated grammar, so 1,234.56 is one thousand two hundred and thirty-four rather than 1, which is what parseFloat returns. The rounding is to the number of decimal places the target currency actually has, so the yen gets none and the dinar gets three, instead of two for everything. And the rate is named along with its provenance, so you can see whether it was published for this pair or derived through a third currency. Where a single amount could be read two ways, both readings are shown rather than one being chosen in silence.
Enter an amount, pick two currencies, and get a conversion that shows its working: the rate it used and where that rate came from, the product before any rounding, how many decimal places the target currency actually has, and what converting straight back would give. The rates come from a public daily feed and carry the date they were published for. Everything done with them can be checked, and is.
A currency converter has two halves, and only one of them is its own work. The rates come from an external feed and cannot be verified from inside a web page: what the feed says is what there is. Everything else, reading the amount, multiplying, rounding, formatting, is the tool's, and that is where converters quietly go wrong.
Reading the amount comes first. Typing 1,234.56 into the previous version of this tool produced a conversion of 1, because `parseFloat` stops at the comma, and nothing on the page said so. The amount is now read with a stated grammar: ECMA-262 decimal literals, with the group and decimal separators of three locale families from Unicode TR35 around them, plus a currency symbol or code that is recognised and ignored and accounting parentheses that mean a negative. 1,234.56 and 1.234,56 and 1 234,56 are all read as the same amount. Where a single value genuinely cannot settle which convention it is written in, which is exactly the case for 1,234, both readings are shown rather than one being picked in silence, and the format can be changed to say which was meant. An amount that cannot be read at all is refused by name, so 0x1F is turned down as a radix prefix rather than becoming 0.
Then the rounding. ISO 4217 gives every currency a minor unit, and it is not two for everything: the yen and the won have none, the Bahraini and Kuwaiti dinars have three, and the Chilean unit of account has four. The previous version rounded everything to two places unless the answer was under 0.01, in which case it used six, or over a million, in which case it used a locale format with grouping. Measured on a fixed table, four of six target currencies were shown with the wrong number of decimal places, and one currency pair was displayed in three different formats depending on how much was being converted. Now the number of places is the currency's own, read from CLDR through Intl, and it is the same at every size. Bitcoin and Ethereum are not ISO 4217 currencies at all, so eight places is stated on the page as a convention rather than presented as a standard.
The rate itself is named. The tool fetches the row published for the currency you are converting FROM, so the figure used is one the source printed rather than one derived by dividing two others. When that row cannot be reached, a cached row for another currency is used instead and the result is labelled a cross rate through that currency, because it then carries the rounding of two published figures rather than one. Show working spells all of this out: the amount as it was read, the rate and its provenance, the product before rounding, how far rounding moved it, and what converting back gives.
That last figure is worth understanding. Converting 100 JPY to USD and back returns 101 JPY, and no arithmetic error is involved: one yen is worth about two thirds of a cent, so half a cent of unavoidable rounding in dollars is three quarters of a yen coming back. The tool states the bound that rounding alone can explain and shows the difference against it, rather than pretending the trip was lossless.
One more check the tool can make on rates it did not compute: whether the table agrees with itself. Published rates are rounded to a fixed number of figures, so going from one currency to another through a third does not have to land exactly where the direct rate does. When the difference is big enough to matter the page says so, with the number, because a user comparing two routes deserves to know that a small gap is normal.
Saved pairs are priced from the row published for their own base. In the previous version every saved pair was shown the currently selected currency's rate whatever its own was, so with USD selected, EUR/GBP displayed 0.75 where the real figure was 0.9375: a 25 percent error with nothing on screen to hint at it.
The rate used and its date are both on screen and go into the copied line, which is what an invoice needs behind it. Show working gives the figure before rounding if you need to reconcile against a bank statement.
Yen, won and Icelandic krona amounts have no decimal places. A converter that shows two is inventing precision that does not exist, and this one does not.
The Bahraini and Kuwaiti dinars divide into 1,000 fils. Rounding to two places throws away a real unit of money, which matters when the dinar is worth more than three dollars.
These are mid-market rates. Comparing them with the rate a bank or card actually gave you shows the margin, and the tool is explicit that its figure is the midpoint rather than a price anyone will trade at.
A public daily exchange rate feed, with a fallback source if the first does not answer. The date they were published for is shown above the converter rather than implied, and a table is reused for ten minutes before it is fetched again. If neither source answers, the tool says so and shows no conversion rather than a stale or invented one.
Because each result is rounded to a real number of decimal places, and the two currencies do not have the same precision. Converting 100 JPY to USD gives 0.67, and 0.67 USD back is 101 JPY. The tool shows the difference and the bound that rounding alone can explain, so you can see it is arithmetic rather than a mistake.
Because it has none. ISO 4217 gives every currency a minor unit, and the yen, the won, the Icelandic krona and the Vietnamese dong have zero, while the Bahraini, Kuwaiti and Tunisian dinars have three. The figure comes from CLDR through Intl rather than from a table that would go stale.
Both, and 1 234,56 as well, and any of them with a currency symbol attached. If a value could be read two ways, which 1,234 genuinely can, the page shows both readings and the format selector settles it rather than the tool deciding for you.
A cross rate is two published rates multiplied together to reach a pair the table does not price directly, and it carries the rounding of both. Normally the tool avoids this by fetching the row published for the currency you are converting from. When that row cannot be reached it falls back to a cached one, uses a cross rate, and says so.
No. These are mid-market rates, the midpoint between what buyers and sellers are asking. Banks, cards and payment services add their own margin, so the rate you are actually given will be worse, often by one to three percent.
Live exchange rates are fetched from the open fawazahmed0 currency API (via jsDelivr, with a pages.dev fallback). Only the selected base currency appears in the request; the amounts you enter never leave your device.