Check whether a TLS version is still supported
Type a TLS version and see at once whether it is still supported: TLS 1.3 and TLS 1.2 pass, while TLS 1.0 and TLS 1.1 come back deprecated, each with a short next step for your security review. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Version
- TLS 1.3
- Status
- supported
This TLS version support checker classifies TLS 1.0, TLS 1.1, TLS 1.2, or TLS 1.3 using a clear, fixed interpretation of common industry guidance. It reports whether the supplied version is deprecated, gives a supported status, and provides a short next-step recommendation. Unrecognized version strings fail explicitly instead of producing an uncertain result, making the tool suitable for repeatable reviews, scripts, checklists, and documentation work reliably.
Understand what the result means
A supported result means the protocol version is not generally treated as deprecated by current mainstream industry guidance. In this checker, TLS 1.2 and TLS 1.3 are supported, while TLS 1.0 and TLS 1.1 are deprecated. The classification is deliberately about the protocol version itself.
It does not prove that a particular server is configured securely, that a certificate is valid, or that every enabled cipher suite is appropriate. A TLS 1.2 service can still have weak configuration choices, and a modern client can still fail because of certificate, hostname, or trust-chain problems. Use the returned status as one precise item in a broader security review.
The response includes both deprecated and supported booleans so automation can consume the result without interpreting prose, plus a guidance sentence for reports intended for people. Because the mapping is fixed and deterministic, the same recognized input always receives the same classification, which makes comparisons and audit evidence straightforward.
Enter and normalize a TLS version
Provide one version string at a time. The canonical forms are TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3. Matching is case-insensitive, surrounding whitespace is ignored, and the familiar TLSv1.2 style is accepted as well.
The output always returns a canonical label such as TLS 1.2, which helps normalize values collected from inventories or configuration notes. The checker intentionally rejects bare or unknown values rather than guessing. SSL 3.0, TLS 2.0, words such as latest, and incomplete strings are not silently mapped to a supported protocol.
This strict behavior matters in automated checks because a typo should stop a workflow or create a visible exception, not accidentally pass a policy gate. If you are reading a configuration file, first extract the actual protocol version from its product-specific syntax, then submit the version here. If a system enables several versions, check each version separately and treat any deprecated enabled version as a reason to review the configuration.
Apply the classification in a security review
Use this check when an asset inventory, questionnaire, deployment manifest, or vendor response names a TLS version and you need a consistent first-pass classification. Deprecated TLS 1.0 or TLS 1.1 should normally trigger a migration task: confirm which clients still depend on the old version, enable TLS 1.2 or TLS 1.3, test interoperability, and then remove the legacy protocol. A supported TLS 1.2 or TLS 1.3 result is not the end of the assessment.
Continue by checking certificates, trust chains, hostname validation, cipher and signature choices, library patch levels, and the versions actually negotiated from relevant networks. Requirements can also be stricter than common guidance, especially under a contract, regulatory framework, platform baseline, or internal security standard. In those cases, use the stricter applicable policy as the final authority.
Browser use can support quick manual reviews, while the structured response works well in compliance pipelines and repeatable configuration checks.
What you can do with it
Review a server baseline
Classify every TLS version named in a server or load balancer baseline before approving the configuration.
Normalize vendor questionnaires
Turn differently formatted recognized TLS version answers into a consistent label and support status.
Gate legacy protocol findings
Create a migration finding whenever an inventory entry reports TLS 1.0 or TLS 1.1.
FAQ
Which TLS versions are recognized?
TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3 are recognized, including case-insensitive TLSv notation.
Which versions are considered deprecated?
TLS 1.0 and TLS 1.1 are classified as deprecated. TLS 1.2 and TLS 1.3 are classified as supported.
Does supported mean a server is fully secure?
No. The result covers only protocol-version deprecation, not certificates, cipher suites, implementation patches, or server configuration.
What should I do if a server still allows TLS 1.0?
Plan a migration. TLS 1.0 and TLS 1.1 are deprecated, so find out which clients still depend on them and move them to TLS 1.2 or TLS 1.3. If a system enables several versions, check each one separately.
Why does the checker reject SSL 3.0 or TLS 2.0?
Because it only recognizes TLS 1.0, 1.1, 1.2 and 1.3 and never guesses. SSL 3.0, TLS 2.0, words such as latest and incomplete versions are refused openly instead of slipping through as supported by mistake.
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/security/tls-version-support-check \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"version":"TLS 1.2"}'const res = await fetch("https://api.kit.forhosting.com/security/tls-version-support-check", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"version": "TLS 1.2"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/security/tls-version-support-check",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"version": "TLS 1.2"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/security/tls-version-support-check", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"version":"TLS 1.2"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"version":"TLS 1.2"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/security/tls-version-support-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"version": "TLS 1.2"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "security.tls_version_support_check",
"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
Apply the classification in a security review
The API price is $0.002 per request when you automate the lookup.
Technical questions
What happens for an unknown version?
The request returns an invalid_input error listing the four recognized TLS versions rather than guessing.
How much does an API check cost?
Each API request costs $0.002. The capability performs one deterministic version classification per request.