What does the safety analyzer actually check?

It scans the snippet for every assertion and grades each one. Casting to any is danger because it switches off the type checker for that value. A double assertion (x as unknown as T) is danger because it means the two types do not overlap, so the cast is almost certainly unsound. A non-null ! is a warning because the value may really be null at runtime. A plain x as T narrowing cast is a warning, while an angle-bracket cast or a literal annotation is a caution, and as const is graded ok. Each finding includes the line, the offending text, the reason, and a safer alternative.

When should I use satisfies instead of as?

Use satisfies when you are only annotating a value — typically an object or array literal — and want TypeScript to verify it matches a type without widening the inferred type. const config = { url: "x" } satisfies Config checks compatibility while keeping config.url as the literal "x" rather than Config["url"]. The converter detects literal annotations and recommends satisfies for them; with "satisfies only for literals" on, it will only rewrite those cases when you target the satisfies style.

Why are double assertions like x as unknown as T dangerous?

A direct x as T is rejected by TypeScript when the two types have no overlap. Routing through unknown (or any) suppresses that error, which means you are forcing a conversion the compiler considers impossible. At runtime the value is whatever it actually was — nothing has changed — so the first time you touch a property that does not exist you get a crash. The analyzer flags these as danger and suggests validating the value at runtime (a schema parse) or fixing the upstream type so a direct cast is legal.

Does the converter type-check my code?

No. It uses a tolerant text/regex scanner, not the TypeScript compiler, so it rewrites assertion syntax and grades risk by pattern — it cannot tell you whether a given assertion is actually sound. That limitation is the whole point of the safety pass: assertions bypass the type system precisely so the compiler will not check them, which is why the tool steers you toward runtime guards and schema validation instead.

What safer alternatives does it suggest, and are they real patterns?

Yes. For object-shape casts and as any it scaffolds a type-guard function (isTarget(value): value is Target) with a narrowing if block; for double assertions it offers a Zod schema parse so the type is backed by a runtime check; for non-null ! it suggests an explicit if (value != null) guard or optional chaining; and for literal annotations it offers the satisfies rewrite. The function and schema names are derived from your target type so you can paste them in and fill the body.

Why are angle-bracket assertions discouraged?

The value syntax collides with JSX tags, so it cannot be used in .tsx files and is avoided in React codebases. It is behaviourally identical to as, so the safe default is to convert toward as. The tool can still emit angle-bracket form when you target that style, but it flags existing angle-bracket assertions as a caution and recommends switching them to as.

Type Assertion Converter

Convert TypeScript assertions between styles — as, angle-bracket <T>, and satisfies — and flatten dangerous double assertions across a whole snippet at once. The built-in safety analyzer grades every assertion it finds (as any, x as unknown as T, non-null !, plain narrowing casts), explains why each one is risky, and hands you the safer alternative: a type guard, a schema parse, or a satisfies annotation.

About this ToolHow it works, benefits & use cases

Paste a TypeScript snippet and this tool does two things at once. First it converts assertions between every style — the recommended as form, the JSX-incompatible angle-bracket <T>value form, and the satisfies operator — and it flattens dangerous double assertions (x as unknown as T) down to a single cast, across the whole snippet rather than just the first match. Second, and more importantly, it runs a safety analyzer over every assertion it finds: as any, x as unknown as T, non-null !, plain narrowing casts, and as const. Each one is graded danger, warning, caution or ok, with a plain-English reason it is risky and a concrete safer alternative you can paste straight in — a type guard, a schema parse (Zod), or a satisfies annotation. The tool also promotes satisfies over as wherever an assertion is merely annotating a literal, so you keep the precise inferred type instead of widening it. Everything runs locally in the browser and the snippet plus options live in a shareable URL.

How to Use

1Paste code containing assertions into the input panel, or load one of the built-in examples (mixed/risky, angle-bracket, literal annotation).
2Pick a target style — as, angle-bracket <T>, or satisfies — to rewrite the convertible assertions.
3Toggle "Flatten double assertions" to collapse x as unknown as T into x as T, and "satisfies only for literals" to keep that rewrite scoped to object/array/literal annotations.
4Read the Safety analysis card: an overall score, a count by grade, and a per-finding list with the line, the offending text, why it is risky, and the safer alternative.
5Copy or download the converted output, switch the view to Best practices for a reference cheatsheet, or share the URL with a teammate.

Key Benefits

Converts between as, angle-bracket <T>, and satisfies across the whole snippet, not just the first assertion
Flattens unsafe double assertions (x as unknown as T) to a single cast
Safety analyzer grades every assertion danger / warning / caution / ok with an overall score
Each risky finding ships a concrete safer alternative: a type guard, a Zod schema parse, or satisfies
Promotes satisfies over as when an assertion is only annotating a literal, preserving the inferred type
Flags non-null ! assertions and recommends an explicit null check or optional chaining
Runs entirely in the browser; snippet and options are captured in a shareable URL

Common Use Cases

Auditing a file for as any and double assertions before a refactor or code review
Migrating angle-bracket <Type>value assertions to as so the code is JSX/TSX-safe
Replacing an unsafe data as User with a runtime type-guard or schema-parse skeleton
Switching object-literal as Config annotations to satisfies Config to stop literal types from widening
Teaching a team which assertions are safe (as const) and which silently bypass the type system

converted.ts

1 rewritten, 3 preserved

const user = data as any;
const id = (json as User).id;
const el = document.getElementById('app')!;
const name = response as User;

Safety analysis

0/ 100

2Danger2Warning

Assertion to anyline 1
data as any
Casting to `any` switches off the type checker entirely for this value — every downstream access is unchecked and can crash at runtime.
Narrow with a type guard, or parse the value with a schema (Zod/valibot) so the type is backed by a real runtime check.
Double assertion (unknown as T)line 2
json as unknown as User
`x as unknown as T` is the escape hatch you reach for when TypeScript refuses a direct cast — it means the two types genuinely do not overlap, so the assertion is almost certainly unsound.
Validate the value at runtime before treating it as the target type, or fix the upstream type so a direct conversion is legal.
Non-null assertion (!)line 3
document.getElementById('app')!
The `!` operator tells the compiler the value is never null/undefined. If that assumption is ever wrong you get a runtime "cannot read properties of null" error with no compile-time warning.
Guard with an explicit check (or optional chaining `?.` / a default) so the null case is handled instead of asserted away.
Type assertion bypasses checkingline 4
response as User
`as T` tells the compiler to trust you. If the runtime value is not actually a `T`, nothing catches it until something breaks downstream.
If the value comes from outside your type system (JSON, an API, the DOM) validate it with a type guard or a schema first.

TypeScript with assertions

Paste code

Tip: the analyzer scans every assertion in the snippet — as any, double assertions, non-null !, and plain casts — not just the first one.

Conversion

Target style

Flatten double assertions

x as unknown as T → x as T

satisfies only for literals

only rewrite { ... } / [ ... ] / literals to satisfies

A converter that also lints

Assertions tell the compiler “trust me” — so the dangerous ones never show up as errors. This tool rewrites between the as, angle-bracket and satisfies forms, but its real job is the safety pass: it grades every assertion and pairs the risky ones with a runtime-checked replacement.

satisfies over as

When an assertion is only annotating a literal, satisfies T checks compatibility without widening the inferred type — so you keep the precise literal type and still catch excess or missing properties.

Was this tool helpful?

Share Your Experience

Help others discover this tool!

Share on

Type Assertion Converter

How to Use

Key Benefits

Common Use Cases

Safety analysis

TypeScript with assertions

Conversion

A converter that also lints

satisfies over as

Was this tool helpful?

Share Your Experience

Related tools

Frequently Asked Questions - Type Assertion Converter