ASP File Documentation

Summary

An .asp file is a Classic Active Server Pages script: plain-text HTML mixed with server-side VBScript or JScript that Microsoft IIS runs to produce a web page. The server executes the code and sends your browser ordinary HTML (MIME text/html); you never receive the .asp itself. Developers edit the source in VS Code or Notepad++. If a download arrived as .asp when you expected a PDF, the server mislabeled it — rename it to the real type.

Technical details

FeatureValue
Full nameActive Server Pages (Classic ASP)
File extension.asp
MIME typetext/html (the server's output, not the file)
Format typeServer-side script page (HTML + VBScript/JScript), plain text
DeveloperMicrosoft
Introduced1996 (ASP 1.0, with IIS 3.0)
Runs onMicrosoft IIS (Internet Information Services)
Default languageVBScript (JScript also supported)
Script delimiters<% ... %> and <%= ... %>
Open standardNo — proprietary Microsoft technology
EncodingPlain text (ASCII / UTF-8)
Magic numberNone — it is text; look for the <%@ Language %> directive
SuccessorASP.NET (.aspx, 2002); ASP.NET Core / Razor
StatusLegacy; runs on current IIS as an optional component
Server includes<!--#include file="..."-->
Related extensions.aspx, .asa, .asax, .inc, .vbs, .html
Edit withVisual Studio Code, Notepad++, Visual Studio
Specificationlearn.microsoft.com (Classic ASP docs)
Syntax at a glance

An .asp file is plain text with no signature. Server-side code sits inside <% ... %> delimiters and is run by IIS — it is never sent to the browser. A page usually opens with the language directive <%@ Language="VBScript" %>. The shorthand <%= expression %> writes a value into the response, and <!--#include file="header.inc"--> pulls in shared fragments server-side. Everything outside the <% %> blocks is static HTML.

What is an ASP file?

ASP stands for Active Server Pages, Microsoft's original server-side web technology, introduced in 1996 with IIS 3.0. An .asp file lives on a web server running IIS. When a browser requests a page such as login.asp, the server runs the VBScript or JScript embedded in the file, assembles the result, and returns plain HTML. The visitor never receives the .asp source, only the HTML it produced. That is why .asp appeared in the address bar of countless older corporate, e-commerce, and government sites.

The technology people now call “Classic ASP” is legacy. Microsoft superseded it with ASP.NET (.aspx) in 2002, and modern stacks use ASP.NET Core, Razor Pages, and Blazor. Classic ASP still runs on current IIS through an optional Windows component, but it receives no new development, so .asp is mostly seen on long-established sites and in maintenance work. The rest of this page explains how the file is actually processed, and the two very different situations that bring someone to an .asp file.

The @Language directive and script delimiters

A Classic ASP page is HTML with islands of server code. The code sits between the delimiters <% and %>. A processing directive at the very top of the file selects the scripting engine:

<%@ Language="VBScript" %>
<html>
<body>
  <h1>Hello, <%= Request.QueryString("name") %></h1>
  <%
    Dim i
    For i = 1 To 3
      Response.Write "<p>Line " & i & "</p>"
    Next
  %>
</body>
</html>

The <%@ Language %> directive must be the first line; it tells IIS whether to interpret the script blocks as VBScript (the default) or JScript. The shorthand <%= expression %> is equivalent to Response.Write expression and inlines a value into the output stream. Everything outside the <% %> blocks is static HTML that IIS passes through unchanged. The engine processes the file top to bottom, emitting HTML wherever it encounters static markup or a write, so the byte order of the response mirrors the order of the source.

The intrinsic objects: Request, Response, Session, Server

ASP scripts do their work through a small set of built-in objects that IIS injects into every page. Request reads incoming data: Request.QueryString for URL parameters, Request.Form for POST fields, Request.Cookies for cookies. Response builds the reply: Response.Write appends text, Response.Redirect sends a 302, Response.ContentType sets the MIME type, and Response.BinaryWrite emits raw bytes for a generated file.

Session holds per-user state across requests (keyed by a cookie), Application holds state shared by all users, and Server exposes helpers such as Server.CreateObject (to instantiate a COM component) and Server.MapPath (to turn a virtual path into a physical one). This object model is the whole of Classic ASP: there is no compiler, no type system, and no framework beyond these objects and the scripting language.

Server-side includes and the .inc convention

ASP reuses code with a server-side include directive written as an HTML comment so that it is harmless if the file is ever served as static text:

<!--#include file="header.inc"-->
<!--#include virtual="/shared/db.asp"-->

IIS splices the referenced file into the page before running any script, so an included .inc or .asp fragment can define shared functions, database-connection code, or common markup. The file= form is relative to the current file; the virtual= form is relative to the site root. A common security mistake is putting secrets (connection strings) in a .inc file that the server is willing to serve as plain text, which is why includes are often given the .asp extension so IIS runs rather than reveals them.

ASP versus ASPX, technically

The extensions look similar but the technologies differ sharply. Classic .asp is interpreted: IIS parses the script on every request through the VBScript/JScript engine, with no compilation and no separation of code from markup. ASP.NET .aspx (2002) is compiled: the page is turned into a .NET class, backed by C# or VB.NET, with a full framework, a type system, and a code-behind model that keeps logic out of the markup. Both run on IIS and both send HTML to the browser, so from the outside a page looks the same; inside, ASPX is a compiled application and ASP is a script. New sites use ASPX or newer stacks; .asp survives on sites that predate the switch.

When a site hands you an .asp instead of a document

The most common non-developer encounter with .asp has nothing to do with editing code. You click Download, Print, or Export on an older site and your browser saves a file named report.asp instead of the PDF, image, or spreadsheet you expected. This happens when an ASP handler generates the document (via Response.BinaryWrite) but fails to send a correct Content-Type header or filename. The downloaded file is usually the real document with the wrong extension. Rename report.asp to report.pdf (or .jpg, .xlsx, .docx) and open it normally; if that fails, use the site's proper download link or right-click and choose Save link as. There is no offline “ASP to PDF” converter, because a genuine .asp is a program, not a printable document.

Safety: server-side execution and web shells

The .asp extension is safe to read — opening the source in a text editor never runs anything, because execution only happens inside IIS. The real danger is on the server side. Because IIS executes any .asp in a web-accessible folder, an attacker who can upload a file into that folder can plant a web shell: an .asp page that takes a command from Request.QueryString and runs it through Server.CreateObject("WScript.Shell"), giving remote control of the server. This is why upload directories should never have script execution enabled, and why an unexpected .asp appearing on a server is treated as a compromise.

A downloaded .asp from an untrusted source deserves the same caution as any unknown file: inspect it as text before renaming it, and never let it be dropped into a live web directory. On the client, an .asp in a URL is just a normal web page — the usual phishing caution on login forms applies, but the extension itself carries no client-side code.

References