Detect file line ending style
Find out which line breaks a file really uses: alpha, beta and gamma each ending in CRLF give the style CRLF with 3 breaks and 0 lone LF, and a single stray break marks the file as mixed. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- alpha beta gamma
- Total
- 3
- Style
- CRLF
Inspect raw file text and identify its line-ending convention without changing the content. The detector counts lone LF breaks and Windows-style CRLF pairs, then reports whether the file uses LF, CRLF, or a mixture of both. It is deterministic, language-neutral, and useful for source code, configuration, logs, exports, and generated text. Files with no recognized line breaks return a clear input error instead of an unsupported guess, making the result safe to use in validation and automation.
Supply the raw text exactly as it appears
Send the complete file contents in the text field. Line endings are invisible in most editors, so copying from an application that silently normalizes newlines can change what the detector sees. For the most reliable result, read the file as text while preserving its original characters and submit that raw string directly.
The capability does not need a filename, language, encoding label, or operating-system hint because it examines the newline characters themselves. A Windows break is the two-character sequence carriage return plus line feed, written CRLF. A Unix-style break is a lone line-feed character, written LF.
The scanner treats every CRLF pair as one break and does not count the LF inside that pair a second time. It also counts a final terminating newline when one is present, because that character sequence is part of the supplied file. Empty strings and single-line strings without recognized LF or CRLF characters return an input error: there is no line-ending style to infer from text that contains no applicable break.
Interpret the style and counts
The counts object separates lf from crlf, making the evidence behind the classification explicit. If at least one LF break appears and no CRLF pair appears, style is LF. If at least one CRLF pair appears and no lone LF appears, style is CRLF.
If both counters are greater than zero, style is mixed, even when one convention appears much more often than the other. This strict definition is intentional: a single inconsistent newline can matter to formatters, patch tools, linters, snapshots, and repository policies, so hiding it behind a majority label would lose useful information. The total is simply the two counters added together and can be used as a quick consistency check or as the denominator for your own percentage calculation.
Counts describe newline sequences, not logical lines; depending on whether the file ends with a break, a text file can contain one more logical line than its reported break total.
Use detection before normalization or validation
Line-ending detection is most valuable before another tool rewrites the file. A pre-commit check can reject mixed endings, a migration script can decide which normalization rule to apply, and a build pipeline can explain why a generated artifact changed on one operating system. The detector only reports what is present: it never converts CRLF to LF, adds a missing final newline, edits content, opens a repository, or writes a file.
That narrow scope keeps the result reproducible and lets callers choose the appropriate policy. For example, a cross-platform project may accept either consistent style but reject mixed files, while a Linux-oriented package may require LF exclusively. Generated exports can be sampled after creation to confirm that every row separator follows the promised convention.
If your source may use legacy bare carriage returns, convert or validate those separately; this capability classifies only LF and CRLF as requested.
What you can do with it
Enforce a repository newline policy
Check source and configuration text for LF, CRLF, or mixed endings before accepting a generated change.
Diagnose noisy file diffs
Confirm whether inconsistent newline sequences are making unchanged content appear modified across operating systems.
Validate generated exports
Count row-ending sequences in generated text and verify that the producer emitted one consistent convention.
FAQ
What does one detection cost?
The browser experience can run the same deterministic logic locally.
How is CRLF counted?
Each carriage-return plus line-feed pair counts as one CRLF break, and its LF character is not counted again.
When is a file reported as mixed?
The style is mixed whenever the input contains at least one lone LF break and at least one CRLF pair.
Does this tool change or normalize the text?
No. It only scans the supplied string and reports counts; it never modifies or returns a rewritten file.
Why does a text without line breaks give an error?
An empty text or a single line has no line-ending style to detect, so you get a clear message instead of a guess. Paste the whole file with its original breaks, including the final one, to get a reliable answer.
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/dev2/line-ending-detect \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"first line\r\nsecond line\r\nthird line\r\n"}'const res = await fetch("https://api.kit.forhosting.com/dev2/line-ending-detect", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "first line\r\nsecond line\r\nthird line\r\n"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev2/line-ending-detect",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "first line\r\nsecond line\r\nthird line\r\n"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev2/line-ending-detect", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"first line\\r\\nsecond line\\r\\nthird line\\r\\n"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"first line\r\nsecond line\r\nthird line\r\n"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev2/line-ending-detect", 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": "first line\r\nsecond line\r\nthird line\r\n"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev2.line_ending_detect",
"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
Interpret the style and counts
The response contains style, a counts object, and the total number of recognized breaks.
Use detection before normalization or validation
Because the implementation performs a single deterministic scan with constant-size counters, repeated calls with identical text return identical JSON and do not depend on network services, locale settings, clocks, or machine defaults.
Technical questions
What happens with a one-line file?
If it contains no LF or CRLF break, the capability returns invalid_input because no line-ending style can be detected.