This guide is written for developers who want a practical answer, not a giant theory dump. The goal is to help you understand the decision, use the idea in a real project, and explain it clearly in an interview or code review.

Quick answer

any turns off type checking. unknown forces you to prove what a value is before using it.

Why developers search this

This is a common search for developers moving from JavaScript to TypeScript.

It is a good SEO topic because the search usually happens near a real task: fixing a broken build, choosing an architecture pattern, deploying an app, reviewing AI-generated code, or preparing portfolio proof. Those searches are more valuable than broad “what is programming?” traffic because the reader needs an answer they can use today.

Mental model

Use unknown for values crossing trust boundaries: JSON input, API responses, localStorage, message queues, and caught errors. It keeps TypeScript honest until you narrow the value.

Type How it behaves
any Allows almost anything and can spread unsafely
unknown Accepts any input but blocks unsafe usage
never Represents impossible values after exhaustive checks

Practical example

function getMessage(error: unknown) {
  if (error instanceof Error) return error.message;
  if (typeof error === "string") return error;
  return "Unknown error";
}

This example is intentionally small. In a real codebase, the surrounding details matter: naming, error handling, tests, runtime config, permissions, and how easy the next developer can understand the change.

Implementation checklist

  • Use unknown for external input.
  • Narrow with typeof, instanceof, or validation libraries.
  • Keep any local and temporary when migration requires it.
  • Do not let any leak from shared helpers.
  • Add validation at API boundaries.

Common mistakes

  • Typing caught errors as any by habit.
  • Casting API responses without checking them.
  • Letting any enter reusable utilities.
  • Confusing compile-time types with runtime validation.
  • Using unknown but immediately forcing it with as.

How to explain this in an interview

Use a concrete sentence:

I used this pattern because [problem]. The main tradeoff was [tradeoff]. I verified it by [test or check].

That structure works because it shows judgment. Anyone can name a tool. Strong developers explain why they chose it, what could go wrong, and how they checked the result.

Sources checked

Final takeaway

any turns off type checking. unknown forces you to prove what a value is before using it. Keep the implementation small, verify the edge cases, and write the decision down so the next person can trust it.