HTA (HTML Application)

An HTML Application (HTA) is a Microsoft Windows technology that turns a web page into a full-fledged desktop program. An HTA file is written in ordinary HTML and Dynamic HTML, with program logic supplied by a scripting language supported by Internet Explorer — typically VBScript or JScript. The crucial difference from a normal web page is trust: where a browser confines a page to a security sandbox, an HTA launched through mshta.exe runs as a fully trusted application, free to read and write files, edit the registry, and call system components. Introduced with Internet Explorer 5 in 1999, HTAs gave Windows administrators and developers a way to dress scripts in a graphical interface without ever opening a compiler.

HTA is best understood not as a standalone programming language but as an application packaging and hosting model layered on top of HTML and Windows scripting. It is included here as an encyclopedia entry because, for the better part of two decades, the .hta file was a distinct and recognizable way to build software on Windows — and because it anticipated, by many years, the now-mainstream idea of writing desktop apps in web technologies.

History & Origins

The Internet Explorer Era

HTAs arrived in 1999 as part of Internet Explorer 5. By the late 1990s, Microsoft had invested heavily in Dynamic HTML — the combination of HTML, CSS, the Document Object Model, and client-side scripting — to make web pages interactive. HTAs took that browser technology and asked a different question: what if an HTML document weren’t a web page at all, but a program?

The answer was mshta.exe, a small host executable installed with Windows. When you double-click a file with the .hta extension (or pass it to mshta.exe), the host loads the document into the same MSHTML (Trident) rendering engine that powered Internet Explorer — but without the browser chrome and, critically, without the browser’s security restrictions. The result behaves like any other Windows program: it gets its own window, its own taskbar entry, and full access to the machine.

Microsoft was granted U.S. Patent 6,662,341 for the underlying mechanism on December 9, 2003, describing a method for “writing a Windows application in HTML.”

Why HTAs Caught On

HTAs filled a specific gap. Windows shipped with the Windows Script Host, which could run VBScript and JScript, but those scripts had no native graphical interface — they produced message boxes and input prompts at best. Building a real GUI meant turning to Visual Basic, C++, or later the .NET languages, all of which required development tools and compilation.

An HTA offered a middle path. An administrator who already knew HTML and a little VBScript could lay out buttons, text fields, and tables using familiar markup, then attach behavior with script — and ship the whole thing as a single text file that ran on any Windows machine. This made HTAs especially popular with system administrators, and Microsoft’s own “Scripting Guys” promoted them through tools and tutorials.

Design Philosophy

HTML for the Interface, Script for the Logic

The core idea of an HTA is a clean division of labor borrowed directly from web development: HTML and DHTML define what the user sees, and a scripting language defines what happens. A button is an ordinary <input type="button">; clicking it fires an onclick handler written in VBScript or JScript. Developers already fluent in the browser model needed almost no new concepts to start building desktop tools.

Trust by Design

The defining design decision of HTAs is that they run outside the browser security model. A web page cannot silently write to your disk or registry — an HTA can. This is intentional: an HTA is treated like an executable, and the user who launches one is presumed to trust it as they would any .exe. That full-trust posture is exactly what makes HTAs powerful for administration and exactly what makes mshta.exe a security concern today.

Zero Toolchain

An HTA requires no SDK, no compiler, and no project files. It can be written in Notepad and run by double-clicking. In fact, any existing HTML file becomes an HTA simply by renaming it with the .hta extension. This frictionless authoring story was central to the technology’s appeal.

Key Features

The HTA:APPLICATION Element

What distinguishes an HTA document from a plain HTML page is the optional <HTA:APPLICATION> element, placed in the document’s <head>. It exposes attributes that control the program’s window and behavior:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

<html>
<head>
<title>System Info</title>
<HTA:APPLICATION
    ID="oHTA"
    APPLICATIONNAME="SystemInfo"
    BORDER="thin"
    CAPTION="yes"
    ICON=""
    MAXIMIZEBUTTON="no"
    MINIMIZEBUTTON="yes"
    SHOWINTASKBAR="yes"
    SINGLEINSTANCE="yes"
    SYSMENU="yes"
    WINDOWSTATE="normal" />
</head>
<body>
    <h2>Computer Name</h2>
    <span id="result"></span>
    <br><br>
    <input type="button" value="Get Name" onclick="ShowName()">

    <script language="VBScript">
        Sub ShowName()
            Set net = CreateObject("WScript.Network")
            result.innerText = net.ComputerName
        End Sub
    </script>
</body>
</html>

Common HTA:APPLICATION attributes include:

Full System Access

Through scripting, an HTA can instantiate any registered COM object. This unlocks the full breadth of Windows automation: the FileSystemObject for files, WScript.Shell for the registry and external programs, WMI for system management, ADSI for Active Directory, and the WScript.Network object for network identity. None of this is available to a sandboxed web page.

Choice of Scripting Language

Because HTAs use the same scripting hosts as Internet Explorer, logic can be written in VBScript or JScript (Microsoft’s implementation of JavaScript/ECMAScript). VBScript was historically the more common choice in administrative HTAs, reflecting its dominance in Windows scripting at the time.

Independent of Internet Explorer

A subtle but important point: HTAs depend on the MSHTML rendering engine, not on the Internet Explorer application. Even after a user removes or disables Internet Explorer, the MSHTML engine remains part of Windows, and HTAs continue to function.

Evolution and Status

HTAs never had their own version numbers; their capabilities tracked whatever version of the Trident/MSHTML engine shipped with Windows. As Internet Explorer advanced from version 5 through 11, HTAs inherited the engine’s behavior, though they continued to render in compatibility-oriented document modes by default rather than the latest standards modes.

The broader decline of Internet Explorer reshaped HTA’s standing:

• 2015 — Windows 10 ships with Microsoft Edge, but keeps MSHTML and mshta.exe for backward compatibility.
• June 15, 2022 — The Internet Explorer 11 desktop application is retired. HTAs keep working because they rely on the engine, not the browser.
• October 2023 — Microsoft announces the phased deprecation of VBScript, the scripting language behind many HTAs.
• 2024 onward — VBScript becomes a Feature on Demand in Windows 11 24H2 (enabled by default), with later phases planned to disable and ultimately remove it.

Today, HTAs are best described as a deprecated but still-functional technology. They remain present in Windows 11, but Microsoft no longer enhances the infrastructure and recommends modern alternatives. The long-term VBScript removal plan is the most likely eventual threat to VBScript-based HTAs, though JScript-based ones and the mshta.exe host itself currently remain.

Platform Support

HTA is a Windows-only technology. It depends on mshta.exe and the Windows MSHTML engine, both of which are Windows components with no official equivalent on macOS or Linux. According to Microsoft’s documentation and ongoing presence in the OS, HTAs run on the supported Windows desktop releases, up to and including Windows 11. There is no official cross-platform port, and HTAs do not run in standard Linux-based Docker containers.

Security Considerations

The full-trust model that makes HTAs useful also makes them dangerous. mshta.exe is a signed, built-in Windows binary capable of executing arbitrary script with the privileges of the user who runs it. Attackers exploit this to deliver and run malware while blending in with legitimate system activity — a tactic catalogued in the MITRE ATT&CK framework as technique T1218.005 (System Binary Proxy Execution: Mshta). Security teams routinely monitor or restrict mshta.exe execution for exactly this reason, and its abuse is a major part of why the technology is viewed warily today.

Why It Matters

HTAs occupy an interesting place in computing history as an early, mainstream realization of an idea that would later dominate desktop software: building applications with web technologies. Long before Electron, NW.js, and the wave of HTML-based desktop apps, Microsoft had already shipped a way to write Windows programs in HTML and script and run them as trusted, native-feeling applications.

For a generation of Windows administrators, the HTA was the pragmatic answer to “how do I put a button on this script?” It lowered the barrier to building internal tools to roughly the level of writing a web page, and it did so with no toolchain at all. That accessibility is its legacy.

Its decline is equally instructive. The very full-trust model that made HTAs convenient became a liability in a security-conscious era, and the technologies it leaned on — Internet Explorer’s engine and VBScript — entered managed deprecation. The HTA stands as a reminder that a clever bridge between two worlds can be enormously useful in its moment, and that the same design choices that grant power can later define a technology’s limits.