Integer checker
42 is a whole number, 3.0 counts too because its value is three, and 3.0000001 does not. Type any value and get a strict yes or no, while nonsense like abc is rejected with a message instead of passed off as a no. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Value
- 42
- Value
- 42
You send a value as text — "42", "-7.5", "1e3" — and get back a strict true or false, together with the parsed number. It understands whitespace, signs, decimals and scientific notation, and it refuses to guess: anything that is not a finite number, such as "abc", "Infinity" or an empty string, is rejected with a clear error instead of a silent false.
What counts as an integer
An integer is a number with no fractional part: 42, -17 and 0 are integers; 3.5 and -0.01 are not. The integer checker applies exactly this mathematical definition through the standard Number.isInteger test, with no rounding and no tolerance. That means 3.0 — written with a decimal point but equal to a whole number — returns true, because its value is three, while 3.0000001 returns false.
Scientific notation is resolved first, so 1e3 is an integer (one thousand) and 1.5e-1 is not (0.15). The check is about the value, not about how the value was written: trailing zeros after the decimal point, a leading plus sign and surrounding whitespace are all accepted, because none of them changes what the number actually is. If your application needs string-level strictness instead — for example rejecting "3.0" as typed — that is a formatting rule you should layer on top of this numeric check.
Why non-finite input is an error, not a false
There are two kinds of failure when validating a number. The first is a well-formed number that simply is not an integer — that is a legitimate false. The second is input that is not a finite number at all: "hello", "Infinity", "NaN", "12px" or an empty string.
Collapsing the second case into false hides data-quality problems: a pipeline that receives "Infinity" from a broken upstream division would silently treat it as "not an integer" and continue. Note also that the parser is strict about full-string matches: "42abc" is rejected, never truncated to 42 the way some lenient parsers would do.
FAQ
Is "3.0" an integer?
Yes. The check is about the numeric value, not the notation: 3.0 equals 3, so it is an integer. Written forms like "3.5" or "1.5e-1" are not.
What happens with "Infinity" or "abc"?
Only well-formed numeric input returns true or false.
Does it accept scientific notation?
Yes. "1e3" is parsed as 1000 and returns true; "1.5e-1" is 0.15 and returns false.
Does it round or tolerate near-integers?
No. The check is exact: 3.0000001 is not an integer and returns false. Rounding is a separate decision your application should make explicitly.
Are negative numbers supported?
Yes. -17 is an integer, -0.01 is not. A leading plus sign and surrounding whitespace are also accepted.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/math/integer \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"value":"42"}'const res = await fetch("https://api.kit.forhosting.com/math/integer", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"value": "42"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/math/integer",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"value": "42"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/math/integer", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"value":"42"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"value":"42"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/math/integer", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"value": "42"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "math.integer",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
The integer checker API answers one deceptively simple question: is this value a whole number? Use it to validate form input, API payloads and data imports before a fractional value slips into a field that only accepts whole numbers.
Why non-finite input is an error, not a false
This endpoint separates the two cases deliberately. Valid numeric input always returns a boolean. Anything else returns an invalid_input error with a message explaining what was wrong, so your code can stop, log the offending value and fail fast instead of propagating garbage.
How to integrate it
Send the value in the field called value, always as text; aliases number, n and input are accepted for convenience. The response contains the parsed number and the boolean result, so a single call both validates and converts. A typical integration validates user input before writing to a database column of integer type, filters rows in a CSV import where an ID must be whole, or guards an API endpoint that accepts quantities. Very large magnitudes are worth a thought: beyond 2^53 the double-precision format cannot represent every integer distinctly, so 9007199254740993 is indistinguishable from its neighbours — that is a property of the IEEE-754 format every JavaScript-compatible system shares, not of this check. The same code runs free in your browser on this page for quick tests, and the API costs $0.002 per request when you automate it at scale.
Integration use cases
Validate form and API input
Reject fractional quantities before they reach an integer database column, with a clear error you can show the user.
Filter rows in a data import
Split a column of mixed values into whole and non-whole numbers during a CSV or JSON import, and quarantine the invalid ones.
Guard integer-only endpoints
Check page numbers, counts and IDs at the edge of your service so non-finite or fractional input fails fast instead of corrupting logic downstream.
Technical questions
What does it cost?
$0.002 per request via the API. It is also free to run in your browser on this page.