# nlohmann::basic_json_view::number_token
```cpp
string_view_t number_token() const;
```
Returns the number exactly as it appears in the source text, without parsing or rounding it.
## Return value
The number's token text, as a [`string_view_t`](index.md#member-types) into the document's
[`source()`](../basic_json_document/source.md) text -- for example `#!cpp "1.50"`, `#!cpp "1E2"`, `#!cpp "-0"`, or an
integer literal with more digits than any number type holds (such as a 30-digit integer, which [`get()`](get.md)
and [`materialize()`](materialize.md) can only represent approximately, as a `number_float_t`).
## Exception safety
Strong guarantee: there are no changes to the view or the document it refers to.
## Exceptions
Throws [`type_error.302`](../../home/exceptions.md#jsonexceptiontype_error302) if the value is not a number; example:
`"type must be number, but is string"`.
This exception does not carry a [`JSON_DIAGNOSTICS`](../macros/json_diagnostics.md) path: the view has no
`BasicJsonType` value to point at, so the exception is created without one, even if `BasicJsonType` was built with
`JSON_DIAGNOSTICS` enabled.
## Complexity
Constant.
## Notes
`BasicJsonType` has no counterpart to this function: once a number is parsed into `number_integer_t`,
`number_unsigned_t`, or `number_float_t`, its original textual form (leading zeros aside, which are already rejected
by the grammar; trailing zeros in the fraction; the case and sign of the exponent; ...) is gone. `number_token()` is
useful precisely where that form must survive -- a price or an identifier that must be reproduced exactly, or a
number too large for any of `BasicJsonType`'s number types to hold without loss.
The returned [`string_view_t`](index.md#member-types) always points into the document's
[`source()`](../basic_json_document/source.md) text -- numbers are never decoded into the document's separate string
buffer -- and is valid exactly as long as that text is, see the [validity rules](index.md) of `basic_json_view`.
## Examples
??? example
The example below keeps a price and an order ID exactly as they were written in an incoming order, where
converting them with [`get()`](get.md) would lose information: the price picks up floating-point rounding, and
the order ID -- more digits than a 64-bit integer holds -- can only be approximated as a `#!cpp double` once
`#!cpp materialize()`d.
```cpp
#include
#include
using json_document = nlohmann::json_document;
using json_view = nlohmann::json_view;
int main()
{
// a price and an order id from an incoming order -- both need to be
// reproduced exactly, e.g. for an invoice or an audit log
json_document doc = json_document::parse(R"(
{"price": 19.90, "order_id": 1234567890123456789012345, "quantity": 3}
)");
const json_view order = doc.root();
// number_token() returns the number exactly as written in the source
std::cout << order["price"].number_token() << '\n';
std::cout << order["order_id"].number_token() << '\n';
// get() converts it instead -- the exact source text is gone:
// "19.90" becomes the double closest to 19.9, printed without the
// trailing zero, and the 25-digit order id -- far beyond any 64-bit
// integer -- can only be approximated as a double
std::cout << order["price"].get() << '\n';
std::cout << order.materialize()["order_id"].dump() << '\n';
// an ordinary quantity has nothing to lose either way
std::cout << order["quantity"].number_token() << " == " << order["quantity"].get() << '\n';
}
```
Output:
```json
19.90
1234567890123456789012345
19.9
1.2345678901234568e+24
3 == 3
```
## See also
- [get](get.md) - convert the value to a given type
- [get_string](get_string.md) - the string, without a copy
- [`BasicJsonType::number_integer_t`](../basic_json/number_integer_t.md),
[`number_unsigned_t`](../basic_json/number_unsigned_t.md), [`number_float_t`](../basic_json/number_float_t.md) - the
number types `#!cpp get()` and `materialize()` convert into
## Version history
- Added in version 3.13.0.