Validate an IPv4 address
Find out whether an IPv4 address is written correctly before it goes into a configuration: 192.168.1.25 passes, with each of its four parts between 0 and 255. If something is wrong, the message names the exact part to fix. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- 192.168.1.25
- Address
- 192.168.1.25
- Octets
- 192, 168, 1, 25
An IPv4 address may look simple, yet a misplaced dot, an empty component, a value above 255, or an ambiguous leading zero can make it unsuitable for configuration and data processing. This validator checks one string as strict four-part dotted-decimal IPv4 notation. It either returns a normalized address with its numeric octets or raises an input error that names the precise octet requiring attention, giving people and automated workflows a clear correction path.
Enter strict dotted-decimal IPv4 notation
Provide one address containing exactly four decimal octets separated by three periods, such as 192.168.1.25. Each octet must contain digits only and represent an integer from zero through 255. A single zero is accepted, but padded forms such as 001 are rejected because different software has historically interpreted leading-zero values in inconsistent ways.
Spaces, signs, hexadecimal prefixes, CIDR suffixes, port numbers, and surrounding explanatory text are not part of an IPv4 address and are not silently removed. This strict behavior is valuable at system boundaries: accepting only one canonical notation prevents a value from changing meaning when it moves between a form, database, firewall rule, application library, or command-line tool. The function does not perform DNS resolution or infer an address from a hostname; it evaluates only the submitted string.
Use the octet-specific error to correct bad input
Validation proceeds from the first octet to the fourth and stops at the first problem, so every malformed request produces a focused input error. If a component contains letters, a sign, whitespace, nothing between adjacent periods, or a forbidden leading zero, the message names that component by its human-friendly one-based position. If a numeric component exceeds 255, the message identifies the same octet and explains the permitted range.
An address with too few components points to the first missing octet; an address with extra components identifies octet five as invalid and states that exactly four are required. This is intentionally more actionable than returning only false. A form can place the message beside the relevant value, an import job can attach it to a rejected record, and a developer can immediately see whether the failure concerns structure or range.
No partial or guessed address is returned after a failure. Correct the named octet and submit the complete value again.
Know what validation proves and where to use it
Values in private, loopback, link-local, multicast, documentation, reserved, and other special ranges can all be syntactically well formed, so this capability accepts them when their octets are valid. Apply separate policy checks if your product must allow only public destinations or block particular networks. Execution is deterministic and local: it uses no network access, randomness, clock, external registry, or model.
The same input therefore produces the same result every time. Treat the returned address as normalized syntax, not as evidence about the host behind it.
What you can do with it
Validate a configuration field
Reject malformed server, gateway, or DNS addresses before saving a deployment configuration.
Clean an imported address column
Identify the exact failing octet when a CSV or database import contains invalid IPv4 strings.
Check an allowlist entry
Confirm canonical IPv4 syntax before applying separate network-range and security policies.
FAQ
Are leading zeros accepted?
No. Use canonical decimal notation: zero is valid, but values such as 01 and 001 are rejected as ambiguous.
Does it accept CIDR notation or ports?
No. Submit only an IPv4 address. A suffix such as /24 or :8080 is outside this validator's input format.
Does a valid result mean the host is reachable?
No. The result confirms syntax and octet ranges only; no network request or availability check is performed.
Are private and reserved addresses valid?
They can be syntactically valid and are accepted. Apply a separate range policy when your use case restricts address classes.
What does the error message tell me when an address is wrong?
It names the exact part that needs fixing, counted from one to four from the left. A value above 255, a letter, an empty part between two dots or a padded zero such as 001 each point to that specific part, so you know where to correct.
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/data/ipv4-validate \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"192.168.1.25"}'const res = await fetch("https://api.kit.forhosting.com/data/ipv4-validate", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "192.168.1.25"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/data/ipv4-validate",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "192.168.1.25"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/data/ipv4-validate", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"192.168.1.25"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"192.168.1.25"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/data/ipv4-validate", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"text": "192.168.1.25"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "data.ipv4_validate",
"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.
Limits
max_mb | 25 |
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
Enter strict dotted-decimal IPv4 notation
The input can be supplied through the primary `text` field or the declared `address` and `ipv4` aliases. Successful validation returns `valid` as true, the canonical dotted address, and an array containing the four octets as numbers.
Know what validation proves and where to use it
A successful result proves that the string has the syntax of a canonical IPv4 address: four decimal integers, each within the inclusive range from zero to 255. It does not prove that the address is assigned, reachable, public, safe, or appropriate for a particular network. This validator fits well at API boundaries, configuration editors, allowlist importers, inventory pipelines, log processors, and spreadsheet cleanup stages where malformed strings should be rejected before later work begins. The browser can run the pure logic directly, and an automated API validation costs $0.002.
Technical questions
What does one API validation cost?
Each API request costs $0.002. The same pure validator can also run in the browser.