Submission declined on 20 May 2026 by Devonian Wombat (talk). This draft's references do not show that the subject meets Wikipedia's criteria for inclusion. The draft requires multiple published secondary sources that: provide significant coverage: discuss the subject in detail, not just brief mentions or routine announcements; are reliable: from reputable outlets with editorial oversight; are independent: not connected to the subject, such as interviews, press releases, the subject's own website, or sponsored content. Please add references that meet all three of these criteria. If none exist, the subject is not yet suitable for Wikipedia. If you would like to continue working on the submission, click on the "Edit" tab at the top of the window. If you have not resolved the issues listed above, your draft will be declined again and potentially deleted. If you need extra help, please ask us a question at the AfC Help Desk or get live help from experienced editors. Please do not remove reviewer comments or this notice until the submission is accepted. Where to get help If you need help editing or submitting your draft, please ask us a question at the AfC Help Desk or get live help from experienced editors. These venues are only for help with editing and the submission process, not to get reviews. If you need feedback on your draft, or if the review is taking a lot of time, you can try asking for help on the talk page of a relevant WikiProject. Some WikiProjects are more active than others so a speedy reply is not guaranteed. How to improve a draft Wikipedia:Contributing to Wikipedia – a basic overview on how to edit Wikipedia. Help:Wikitext – how to use the markup Help:Referencing for beginners – how to include references Wikipedia:Article development – how to develop your article Wikipedia:Writing better articles – how to improve your article Wikipedia:Verifiability – make sure your article includes reliable third-party sources You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Add tags to your draft Editor resources Easy tools: Citation bot (help) | Advanced: Fix bare URLs Declined by Devonian Wombat 2 months ago. Last edited by Devonian Wombat 2 months ago. Reviewer: Inform author. Resubmit Please note that if the issues are not fixed, the draft will be declined again.

• Comment: References appear to be a collection of companies promoting themselves and unreliable blogs. Devonian Wombat (talk) 05:46, 20 May 2026 (UTC)

WIT (WebAssembly Interface Type, sometimes expanded as Wasm Interface Type, file extension: .wit) is an interface description language (IDL) used to define the interfaces of WebAssembly components.^[1] Developed under the W3C WebAssembly Community Group as part of the Component Model proposal, WIT provides a language-agnostic way for WebAssembly modules written in different programming languages to describe the functions and data types they import and export, enabling cross-language interoperability without requiring a shared runtime or foreign function interface.^[2]

WIT is the standard IDL for WebAssembly System Interface (WASI) since the release of WASI 0.2 in January 2024,^[3] and is used by runtimes and platforms including Wasmtime, Fastly Compute, Fermyon Spin, and wasmCloud.^[4]

The concept of interface types for WebAssembly was first publicly proposed in August 2019 by Lin Clark of Mozilla, who described a mechanism to let WebAssembly modules exchange high-level values such as strings and records without manual memory-management glue code.^[5] The early work resulted in a formal WebAssembly "interface-types" proposal housed in the W3C WebAssembly Community Group.^[6]

An earlier IDL called WITX, based on the WebAssembly text format, was used to define the APIs of WASI Preview 1 (also known as WASIp1).^[7] As work on the broader Component Model advanced — championed by Luke Wagner, a Distinguished Engineer at Fastly and co-chair of the W3C WebAssembly Working Group — the interface-types proposal evolved into the WIT format that is in use today.^[8] WIT replaced WITX with a richer type system, support for modular interface packages, and the ability to describe both imports and exports of a component in a single definition.^[9]

On 25 January 2024, the WASI Subgroup of the W3C WebAssembly Community Group voted to release WASI 0.2 (WASIp2), which formally adopted the Component Model and made WIT the standard way to define all WASI interfaces going forward.^[3]

A WIT definition is organized around two main constructs: interfaces and worlds.^[1]

An interface is a named collection of type definitions and function signatures that describes a focused piece of functionality—for example, reading from a file system or making an HTTP request. Interfaces are grouped into packages, which carry a two-level namespace (a namespace field identifying the organization or registry, and a package field naming the logical group).^[10]

A world aggregates a set of imported and exported interfaces and types, expressing what features a component offers and what features it depends on. Worlds serve as the compilation target: a component author selects a world, and the component's binary must satisfy all of its imports and exports.^[1]

WIT supports primitive types (booleans, integers of various widths, floating-point numbers, characters, and strings) as well as compound types including records, variants (tagged unions), enums, flags (bitfield sets), tuples, lists, options, and results.^[11] The type system is designed so that every WIT type can be mechanically lowered to the Canonical ABI, the binary calling convention that components use at the boundary.^[12]

Because WIT definitions are independent of any source language, toolchains can generate idiomatic bindings automatically. For example, the wit-bindgen project produces Rust, C, C++, Go, and C# bindings from a .wit file, while Jco targets JavaScript and TypeScript.^[13] This allows a component written in one language to be consumed by a host or another component written in a different language without hand-written FFI code.^[14]

WIT is integral to the server-side and edge-computing WebAssembly ecosystem. Fermyon's Spin framework uses WIT-defined interfaces to let developers write serverless functions in any supported language and deploy them on Fermyon Cloud or self-hosted infrastructure.^[15] The Cloud Native Computing Foundation (CNCF) incubation-stage project wasmCloud relies on WIT to define the capability contracts between application components and infrastructure providers; American Express has used wasmCloud to build an internal function-as-a-service platform built on WebAssembly components.^[16] Microsoft has adopted WIT for WebAssembly-based extension development in Visual Studio Code.^[13]

Industry analysts at InfoWorld and The New Stack have characterized the Component Model (and by extension WIT) as a potential enabler of a "Docker moment" for WebAssembly, in which portable, composable components could complement or replace containers in cloud-native deployments.^[17][18]

• WebAssembly
• WebAssembly System Interface
• Interface description language
• Web IDL
• Protocol Buffers
• Bytecode Alliance

• WIT Reference — Bytecode Alliance documentation
• WIT specification — W3C WebAssembly Community Group (GitHub)
• Interface Types proposal — original W3C proposal repository
• WASI.dev — official WASI website listing WIT-defined interfaces
• wit-bindgen — guest-language bindings generator

WebAssembly

Category:Interface description languages Category:WebAssembly Category:World Wide Web Consortium standards Category:Computer file formats