A large proportion of the computers in this world manipulate money, so it's always puzzled me that money isn't actually a first class data type in any mainstream programming language.
Unfortunately JSON is no different. This document tries to change that by proposing and comparing different styles to represent money, some inspired by external sources and some based on our own experience.
Before we dive into details, always keep the following in mind. However you desire to format money in JSON, nothing changes the fact that you should...
Never hold monetary values [..] in a float variable. Floating point is not suitable for this work, and you must use either fixed-point or decimal values.
We identified the following styles that all of different advantages and disadvantages that are discussed in their respective section.
| Style | Expressive | Arithmetic | Pitfalls / Misuses |
|---|---|---|---|
| Decimal | ✔ | ✔ | Precision |
| Quoted Decimal | ✔ | ✘ | Parsing |
| Fixed Point | ✘ | ✔ | Mixed scales |
| Mixed | ✘ | ✔ | Consistency |
The most straightforward way to represent a monetary amount would be a base-10 decimal number:
{
"amount": 49.95,
"currency": "EUR"
}It's expressive, readable and allows arithmetic operations. The downside is that most JSON decoders will treat it as a floating point number which is very much undesirable.
Most programming languages have support for arbitrary-precision decimals and JSON decoders that can be configured to use them. In general it can be considered to be a problem of the implementation, not the format itself.
Same as Decimal but quoted so your JSON decoder treats it as a string:
{
"amount": "49.95",
"currency": "EUR"
}It solves the precision problem of decimals on the expense of performing arithmetic operations on it. It also requires a two-phase parsing, i.e. parsing the JSON text into a data structure and then parsing quoted amounts into decimals.
A value of a fixed-point data type is essentially an integer that is scaled by an implicit specific factor determined by the type.
{
"amount": 4995,
"currency": "EUR"
}The implicit scaling factor is defined as (0.1 raised to the power of) the currency's default number of fraction digits.
In rare cases one might need a higher precision, e.g. to have sub-cent. In this case the scale can be defined explicitly:
{
"amount": 499599,
"currency": "EUR",
"scale": 4
}The downside with fixed-point amounts is that reading them is a bit harder and arithmetic with mixed scale amounts can be tricky and error-prone.
As a way to counter all negative aspects of the styles above one idea would be to have a single object that contains all of the formats:
{
"decimal": 49.95,
"quoted_decimal": "49.95",
"fixed_point": 4995,
"scale": 2,
"currency": "EUR"
}Decoders can choose the representation that fits them the best. Encoders on the other hand have the harder task by providing all of them and making sure that all values are in fact consistent.
| Language | Implementation |
|---|---|
| C# | decimal |
| Java | java.math.BigDecimal |
| JavaScript | decimal.js |
| Python | decimal.Decimal |
- Coinkite: Currency Amounts
- Culttt: How to handle money and currency in web applications
- Currency codes - ISO 4217
- LocalePlanet: ICU Currencies
- RFC 7159: The JavaScript Object Notation (JSON) Data Interchange Format
- Stackoverflow: What is the standard for formatting currency values in JSON?
- Stackoverflow: Why not use Double or Float to represent currency?
- TechEmpower: Mangling JSON numbers
- Wikipedia: Fixed-point arithmetic