Q: When using {{convert}} why does the answer sometimes seem a bit off?
A: This template takes into account the precision of the supplied value and generally rounds the output to the same level of precision. If you need to change from the default output precision, see rounding.
Note: This can cause whole numbers that end in one or more zeroes to be converted less accurately than expected.
Q: What are all the possible units (kg, lb, m, cm, ft, in, °C, °F, km, mi, nmi, mph, km/h, and so on)?
Q: I've been using Convert for some time and am pretty comfortable with its basic features. Does it have other features which it would be worth my while to learn about?
Template:Convert is permanently protected from editing because it is a heavily used or highly visible template. Substantial changes should first be proposed and discussed here on this page. If the proposal is uncontroversial or has been discussed and is supported by consensus, editors may use {{edit template-protected}} to notify an administrator or template editor to make the requested edit. Usually, any contributor may edit the template's documentation to add usage notes or categories.
Any contributor may edit the template's sandbox. Functionality of the template can be checked using test cases.
Template:Convert has an RfC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you.
We have board feet as a measure of volume - n board feet is the volume of a board 12 inches wide by 1 inch thick, of length n feet. Therefore, 1 board foot is 144 cubic inches:
{{convert|1|board foot|cuin|0}} → 1 board foot (144 cu in)
and 12 board feet is 1 cubic foot:
{{convert|12|board foot|cuft}} → 12 board foot (1.0 cu ft)
But a nominal "two-by-four" might be as small as 1.5 x 3.5 inches, because of planing and other processing, so it's not an exact size, so I don't think including it as a conversion is useful. --Redrose64 🌹 (talk) 20:59, 27 July 2025 (UTC)[reply]
Not clear what you want. Volume? Area? Length? Can you give an example of what it would look like and how you would like to invoke it. Stepho talk23:14, 27 July 2025 (UTC)[reply]
Sure: in Wall I had to use {{nowrap|2 × 3 s}} ({{cvt|1+1/2|x|2+1/2|in|mm|disp=comma}}) or {{nowrap|2 × 4 s}} ({{cvt|1+1/2|x|3+1/2|in|mm|disp=comma}}) yielding 2 × 3 s (1+1⁄2 in × 2+1⁄2 in, 38 mm × 64 mm) or 2 × 4 s (1+1⁄2 in × 3+1⁄2 in, 38 mm × 89 mm).-- Carnby (talk) 05:30, 28 July 2025 (UTC)[reply]
I saw your entry at Wall#Temporary_wall. I had to read it a few times before I understood it. I think many readers from outside America might never decipher it. I think it means that you build a frame with wooden posts of 2" x 4" cross section and cover it with plaster board. It assumes an American practice and this will differ in other parts of the world (eg, in China brick and mortar is cheaper even for temporary walls because wood is expensive). Sadly, the nominal 2" x 4" cross section might actually be only 1+1⁄2" × 3+1⁄2" (presumably lumbar companies cost cutting by making it thinner). I think we are asking convert too much - it falls into what men mean when they say "12 inches" (talking about fish of course :) . The nominal 2x4" can be almost any size the company thinks it can get away with, making a mockery of both economics and any attempt to nail down (pun not intended) a conversion factor to either real inches or mm. Stepho talk06:24, 28 July 2025 (UTC)[reply]
Lumbar company
Stepho, AFAIK you're a sensible person, but everything you just said is nonsense. 2x4s cannot be "almost any size", but are a very specific size, for reasons that must surely be obvious. That that size isn't literally 2 inches by 4 inches is for historical reasons having nothing to do lumbar companies (or even lumber companies) cutting costs or getting away with something. See Lumber#North_American_softwoods. EEng21:27, 28 July 2025 (UTC)[reply]
I stand corrected, 2x4 is apparently a standardised size in America. I'm interested to see what size (in mm) the rest of the world uses for a 2x4. I still think that entry at wall is a bit too Americanised for non-American readers to understand but that's outside of convert's scope. Stepho talk01:54, 29 July 2025 (UTC)[reply]
Cosmology articles like Chronology of the universe use MeV and K interchangeably, but convert does not like energy -> temperature. Its just scale factor, 11.6K to 1eV. Is there another way to do this? Of course we can do it by hand but I thought I would check. Johnjbarton (talk) 23:44, 3 August 2025 (UTC)[reply]
I feel that in Wikipedia, we gain by avoiding units that are not interpretable to the average reader. Supporting conversions such as this unfortunately encourages this use. —Quondum13:58, 4 August 2025 (UTC)[reply]
I agree that consistent use of non-exotic units is a good goal. But which unit do you consider not interpretable by the average reader, 1015 K or 150 GeV? I don't really view these as things users try to make sense of so much as a kind of index between cosmology and particle physics data.
The issue in my case is that different sources use one or the other, sometimes both. Effective comparison across sources requires conversion. Johnjbarton (talk) 16:21, 4 August 2025 (UTC)[reply]
My inclination would be to present temperatures with the unit kelvin, as the average reader knows that this is a unit of temperature, even when the value is huge, whereas the eV is not obviously a unit of temperature, and often gets used as a unit of mass, wavenumber, you name it. I expect any reader at least being able to interpret 1015K as "oh, that is an exponentially large temperature", versus "150 GeV", which many might just gloss over as a non-understandable physics-y thing. As to sources, these are to allow verification (or further study), but we do not need to make it that similar to the source. The reader who does not know how to convert "150 GeV" in the source to a temperature has no idea what "150 GeV" means in the context, anyway. It would be perfectly reasonable to put a footnote in an article to the effect that "Particle physics texts often the use the quantity kT to represent temperature, with the unit electronvolt (eV). A temperature of 1 eV corresponds to 11604 K.", which would ease their encounters with units in use elsewhere. —Quondum17:10, 4 August 2025 (UTC)[reply]
With reference to your comment about indexing, I see the time being the primary index. Devoting a column to indexing on another parameter such as temperature seems too special-purpose and redundant. —Quondum18:54, 4 August 2025 (UTC)[reply]
nbsp capability
Village Pump referred me here. Have run into this issue on several articles, one example occurring in the lead for Chula, Virginia (at least with the screen resolution that I'm using): Is there a way to force the template to put a nonbreaking space between numeral and units displayed in the article text, so as to reliably generate "7 miles (11 km)"? A single good example of the correct syntax might suffice. — HelpMyUnbelief (talk) 00:14, 5 August 2025 (UTC)[reply]
This seems to do it:
{{convert|2|mi|km|disp=preunit| }} → 2 miles (3.2 km)
Indeed that's what the MOS says...but we've got to be overlooking something. Surely the intention of that rule was not that article text like this should be acceptable:
The area is served by the post office 7 miles (11 km) southwest.
That's exactly the intent of MOS. A line break can occur between any 2 words. There is no special case for between numbers and units. E.g, this is also acceptable:
The man was John Doe from the United States. He lived 7 miles out of town.
Do note MOS:NBSP: It is desirable to prevent line breaks where breaking across lines might be confusing or awkward. The first example provided by that guideline is 19 kg. The guideline also provides a good case where {{convert}} might be used but preventing a break is undesirable, specifically tables, since horizontal space is precious. – Daℤyzzos (✉️ • 📤) 10:00, 5 August 2025 (UTC)[reply]
The idea that editors should be able to override line break defaults on a case-by-case basis seems good, and I agree with HelpMyUnbelief for the need in this example.
The bottom line is that convert follows MOS and proposed changes should be discussed there. Convert puts nbsp in 19 kg but a space in 19 kilograms because that is what MOS:UNITNAMES specifies. Thanks Quondum for pointing out that there is no "Wrapping and line breaking" section at Help:Convert despite there being a link to it at Template:Convert#Wrapping and line breaking. It turns out that I removed the section. The original is at October 2023. I hoped Help:Convert would focus on common usage examples—how do you do X. But people started expanding the docs here (Template:Convert/doc), then moved stuff to Help:Convert when this page became too bloated. I don't think there is anything in the section I removed that should be retained because it can be summed up as "convert follows MOS". The details bloat whatever page they are on. If someone wants to restore it, please put it here rather than using Help:Convert as an overflow page. Or maybe make another doc page for techo details. Johnuniq (talk) 03:50, 6 August 2025 (UTC)[reply]
Historical note: During a major overhaul of WP:MOSNUM some ten years ago, the text Guidance on the use of non-breaking spaces ("hard spaces") is given in some sections below, but not all situations in which hard spaces ( or ) or {{{1}}} may be appropriate are described was added (by me, I think). It has long been my intent to add specific guidance at each point in MOSNUM it's needed, but every time I think of actually doing that I get a headache. EEng15:38, 8 September 2025 (UTC)[reply]
"Limitations" section
I propose a change to the first sentence of "Limitations".
Instead of this:
This is a list of features that the module may be expected to support, but which will not work.
I recommend this:
The following strategies may seem right for this module, but they will not work.
I think "a list of features" is exactly the wrong thing to say - isn't it really a list of non-features, but ones that people are likely to try anyway?
So I just found that {{cvt|5|hectares}} does’t work which is weird because {{cvt|5|acres}} does. So I would love to get that alias setup. I believe all that is needed is to insert the snippet below at line 326 on Module:Convert/data.
New units are added at Module:Convert/extra first. Changes to convert are bundled and done together (overhead of changes affecting 1.25 million transclusions + sanity checking). The issue concerns whether plurals for all common units should be defined, and what is a common unit. Have a look at Module:Convert/documentation/conversion data to see that there are too many strange units. I see the point that "hectares" is a natural way of speaking about that unit so maybe it is a good candidate, but are there others that should be done. Johnuniq (talk) 03:10, 11 September 2025 (UTC)[reply]
3 dimensional measurements
Is there a way that I’m not seeing to only have the units printed one time when displaying 3 unit measurements? For example:
{{cvt|3 x 5 x 6|in|cm}} → 3 in × 5 in × 6 in (7.6 cm × 12.7 cm × 15.2 cm)
What I was hoping to achieve is:
{{cvt|3 x 5 x 6|in|cm}} → 3 × 5 × 6 in (7.6 × 12.7 × 15.2 cm)
It is at Help:Convert#Ranges. The background is that the MOS requires the behavior that x implements. (I seem to recall some recent MOS discussions where quite a few people suggested that should be relaxed?) I retained xx in convert as a workaround for the occasional cases where the MOS guideline may not give a good result. Johnuniq (talk) 08:51, 16 September 2025 (UTC)[reply]
How irritating. Another retained but not-standard range is *. I faced a lot of pushback for keeping * and xx and it appears that somewhere the documentation at Help:Convert was "fixed" to remove what were considered to be deprecated features. I think I must have restored xx to Help:Convert but failed on *. Using * gives no spacing:
Generally speaking, if your question is "Can Convert do X?", you can bet the answer is Yes. Convert is like a Swiss Army Knife. EEng07:27, 26 September 2025 (UTC)[reply]
I am planning to release a new version soon. The motivation is to introduce parameter error=x which means that convert would either work (and error=x would have no effect), or would display x instead of the usual convert error. I want this for at least one infobox (Template:Infobox food) which calls convert with text that is often a number, but which can be anything. For example, the infobox might call {{convert|123|kcal}} (which would work), or it might call {{convert|123 (per biscuit)|kcal}} (which would cause convert to return an error which the infobox would hide using #iferror). In the latter case, convert calls Module:Convert/extra to determine if the extraneous text is an "extra" unit. That means that many of the "what links here" entries for that module are false hits. I periodically check that list to see what problems have occurred, and to see what units defined in the extra module are being used.
Using the new parameter, the infobox would not need #iferror. Instead, it would call {{convert|123 (per biscuit)|kcal|error=123 (per biscuit)}} which would display "123 (per biscuit)" instead of an error. The change is in the sandbox, examples:
Another minor change in the module is for projects that use variable names where the unit name can vary depending on the value. At ukwiki, they want a fraction slash to be detected as an alternative to a plain slash when used in a value with a fraction (such as 1+3/4). The name of a unit can be different if a fractional value is used.
The October 2024 release changed units mile and miles to include abbr=off on the principle that if someone wants to display the symbol "mi", they can use that as the input. If "mile" is used, the wanted output is probably "mile" or "miles". Any thoughts on doing the same for the following?
feet inch inches meter meters metre metres yard yards liter liters litre litres
Unit foot is not in that list because it has a special purpose, namely its plural form is "foot", not "feet". The singular form is currently "1 ft" if abbreviated. That could be changed to "1 foot". Thoughts? Johnuniq (talk) 07:23, 2 October 2025 (UTC)[reply]
For me, I find "mi" an unusual abbreviation not often used in the wild, so I like the full spelling of "mile" and "miles".
The others listed have well known and well used abbreviations of ft, in, m, yd, L. So I would continue using the short form for them. Stepho talk23:17, 2 October 2025 (UTC)[reply]
Good points. But why would someone write "liter" if they wanted "l" to be displayed? Maybe liter is unambiguous in the wikitext and they hope convert will display the wanted symbol? Anyway, I'm always happy to avoid changes! Johnuniq (talk) 00:38, 3 October 2025 (UTC)[reply]
Option error=x is new. The value x is any text which may be empty. If no error occurs in the conversion, this option has no effect. Otherwise, the result is x (no error occurs).
Some projects such as Ukrainian Wikipedia use variable names where the unit name can vary depending on the value. That feature now accepts a fraction slash as well as a plain slash in the wikitext for the input value of a fraction (such as 1+3/4).
The error=x option will be tried at {{Infobox food}} to replace:
