ASPX File Documentation

---

Technical details

Feature	Value
Full name	Active Server Page Extended (ASP.NET Web Form)
File extension	.aspx
Response MIME type	text/html
Format type	Server-side web page source (text): HTML + ASP.NET markup
Text encoding	UTF-8
Developer	Microsoft
Introduced	2002 (ASP.NET 1.0, .NET Framework)
Executed by	ASP.NET runtime on IIS (Internet Information Services)
Languages	C# or VB.NET (server side); HTML, CSS, JavaScript (client side)
First line (typical)	<%@ Page Language="C#" ... %>
Magic number	None — plain text
Code-behind file	.aspx.cs (C#) or .aspx.vb (VB.NET)
Compiled to	A .NET class (a Page subclass), then IL, then native
Server controls	<asp:... runat="server"> rendered to HTML
State mechanism	ViewState (hidden __VIEWSTATE field), Session, cookies
Open standard	No — Microsoft framework
Status	Legacy; superseded by Razor Pages (.cshtml) and Blazor
Related extensions	.asp, .ascx, .ashx, .cshtml, .master, .aspx.cs
Specification	learn.microsoft.com/aspnet/web-forms/

What is an ASPX file?

ASPX stands for Active Server Page Extended. It is the file extension for an ASP.NET Web Form, Microsoft’s server-side web-page technology, introduced with the .NET Framework in January 2002 as the successor to classic ASP. An .aspx file lives on a web server running IIS. When a browser requests a page like account.aspx, the server runs the page’s code, builds the result, and returns ordinary HTML. You never receive the .aspx file itself; you see the HTML it produced. That is why .aspx so often appears in the address bar of banking, government and corporate sites built on ASP.NET.

Because an .aspx is processed server-side, it is not static the way an HTML file is: its output depends on code and live data, which makes it roughly analogous to a PHP file in the LAMP world. There are two distinct situations a person meets an .aspx in. Most non-developers meet it by accident — a download arrived named something.aspx instead of the PDF or invoice they expected (covered near the end of this page). Developers meet the .aspx as source code: the markup file that, with its code-behind, defines a page. The middle sections explain how that source is structured and how the server turns it into a page.

The @ Page directive and code-behind

A Web Form almost always begins with a page directive, a line wrapped in <%@ ... %> that configures the page before any markup:

<%@ Page Language="C#"
        AutoEventWireup="true"
        CodeBehind="Default.aspx.cs"
        Inherits="MyApp.Default" %>

Language sets the server-side language (C# or VB.NET). Inherits names the .NET class the page derives from — the code-behind class. CodeBehind points at the physical source file that holds that class (its use is a Visual Studio convention; the runtime binds by Inherits). This is the code-behind model: the .aspx holds the markup and layout, and a separate .aspx.cs (C#) or .aspx.vb (VB.NET) file holds the program logic. The two are compiled together into one class. AutoEventWireup="true" tells ASP.NET to connect page lifecycle events, such as Page_Load, to methods of that name automatically. Other directives appear too: <%@ Register %> to bring in a user control, <%@ Master %> at the top of a master-page file, <%@ Import %> to add a namespace.

Server controls and the runat attribute

The body of an .aspx is HTML with ASP.NET additions. The pivotal attribute is runat="server": any element carrying it is handled on the server rather than passed through as literal markup.

<form id="form1" runat="server">
  <asp:Label ID="Greeting" runat="server" />
  <asp:TextBox ID="NameBox" runat="server" />
  <asp:Button ID="Go" runat="server" Text="Submit"
              OnClick="Go_Click" />
</form>

These <asp:...> tags are server controls. They are not HTML the browser understands; the runtime instantiates a matching .NET control object for each, runs its logic, and asks it to render itself into ordinary HTML. An <asp:Button> becomes an <input type="submit">; an <asp:GridView> becomes a full <table>. The OnClick="Go_Click" wires the button’s server-side click to a method in the code-behind. Two inline syntaxes complete the picture: <% ... %> runs a block of code during render, and <%# ... %> is a data-binding expression evaluated when the control is bound to data. A page is required to have a single <form runat="server">, because Web Forms posts the whole form back to itself.

ViewState and the postback model

HTTP is stateless, but Web Forms is built to feel stateful, and the mechanism is ViewState. When a page renders, ASP.NET serialises the state of its server controls, Base64-encodes it, and writes it into a hidden field named __VIEWSTATE in the form. On the next postback — when the user submits the form — the browser sends __VIEWSTATE back, and the runtime deserialises it to restore each control to the state it was in, then raises the server-side events (like the button click) that the postback represents. This is why an ASP.NET page can remember what was in a grid or a textbox across a round trip without you writing any state code, and also why __VIEWSTATE can grow into a large hidden blob on control-heavy pages. Because that blob is deserialised on the server, its integrity matters: ASP.NET protects it with a machine key (MAC and, by default, encryption), and a leaked machine key is a serious vulnerability precisely because it lets an attacker forge ViewState the server will trust.

Compilation and the page lifecycle

An .aspx is never interpreted line by line at request time in the way a static file is served. The first time a page is requested, ASP.NET compiles the markup: it generates a .NET class from the .aspx (merging it with the code-behind named by Inherits), compiles that to Intermediate Language in an assembly, and JIT-compiles it to native code. The assembly is cached, so later requests skip straight to execution — which is why the first hit after a deployment is slower. Each request then walks the page lifecycle: Init, Load (where Page_Load runs and IsPostBack distinguishes a fresh request from a postback), control events, PreRender, then Render (where every control emits its HTML) and finally Unload. The bytes the browser receives are the concatenated render output; the directives, server controls and code-behind never leave the server.

Why a rogue .aspx is a remote code execution risk

The same property that makes Web Forms powerful — the server compiles and runs code inside the .aspx — is what makes a maliciously planted .aspx dangerous. This is the classic web shell. If an attacker can write a file into a directory that IIS serves, an .aspx containing a server-side code block will be compiled and executed the moment it is requested, running with the web application’s privileges:

<%@ Page Language="C#" %>
<script runat="server">
  void Page_Load(object s, EventArgs e) {
    System.Diagnostics.Process.Start("cmd.exe", "/c " + Request["c"]);
  }
</script>

A single request such as shell.aspx?c=whoami then runs an arbitrary command on the server. This is not a flaw in the format — it is the intended execution model turned against the host, and it is a common post-exploitation payload after a file-upload vulnerability or a compromised admin panel. The defensive implications are concrete: never allow user-uploaded files to land in a directory where the ASP.NET handler will execute .aspx, store uploads outside the web root or on a handler that serves them as inert bytes, and treat any unexpected .aspx appearing on a server as a potential shell.

For an ordinary visitor the risk is different and low. When .aspx merely appears in a URL it is just a web page — treat the site as you would any site and watch for phishing on login pages. A downloaded .aspx is inert on your own machine: your computer has no web server to execute it, so opening it in a text editor to see what it is is always safe. It only runs code when it sits inside a live ASP.NET application on a server.

When an .aspx downloads instead of your PDF

The most common non-developer encounter is a document that arrives with the wrong extension. You clicked “Download statement” or “Print invoice” on a bank or government site and got something.aspx instead of a PDF. What happened is that the server generated the document through an .aspx handler but failed to send a correct Content-Type and filename, so the browser saved the response under the page’s own name. The downloaded file is usually the real document with the wrong extension. Renaming file.aspx to file.pdf (or .jpg, .xlsx, .docx — whatever you expected) and opening it normally fixes it in most cases. If the rename does not open cleanly, the page generates the document dynamically and you should use the site’s proper download link or right-click and choose “Save link as”. There is no offline “aspx to PDF” converter, because a genuine .aspx is a program, not a printable document.

Frequently asked questions

Why did a website download an .aspx file instead of a PDF?

The server built your document through an ASP.NET page but sent the wrong file type and name, so the browser saved the response as .aspx. The download is usually the real PDF with the wrong extension — rename it from .aspx to .pdf and open it. If that fails, use the site’s proper download link or right-click and “Save link as”.

What does .aspx at the end of a web address mean?

It means the page is an ASP.NET Web Form running on a Microsoft IIS server. It is part of the URL, not a file you download: the server executes the page and sends your browser plain HTML. Seeing .aspx in a URL simply tells you the site is built on ASP.NET.

What does runat="server" actually do?

It marks an element for server-side handling. ASP.NET creates a .NET control object for any tag with runat="server", runs its logic, and has it render itself into ordinary HTML before the response is sent. Without that attribute, the element is passed through to the browser as literal markup.

References

• Microsoft Learn — ASP.NET Web Forms overview
• Microsoft Learn — ASP.NET page life cycle
• Microsoft Learn — Work with code-behind class files

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.