ASP.NET File Upload with a Progress Bar — and How It Differs from Classic ASP
Two different platforms that share three letters — what carries over, what does not, and where to go next.
Quick answer, so you are not stuck on the wrong page. This site is about
Classic ASP — VBScript in .asp files. If your project is
ASP.NET (.aspx, Razor, MVC, Core or Blazor), the code here will not compile
for you. Jump to which uploader belongs on your stack.
Why the two get confused
They share three letters and almost nothing else. Classic ASP shipped in 1996 and runs interpreted VBScript. ASP.NET arrived in 2002 as a compiled framework on the CLR. Microsoft named the successor after the predecessor, and twenty-odd years later people still land on Classic ASP answers while searching for ASP.NET ones — which is very likely how you got here.
| Classic ASP | ASP.NET | |
|---|---|---|
| File extension | .asp | .aspx, .cshtml, .razor |
| Language | VBScript / JScript, interpreted | C# / VB.NET, compiled |
| Reading an upload | Request.BinaryRead, you parse the MIME parts | The framework parses it and hands you file objects |
| Built-in upload support | None | Yes — the framework models uploaded files directly |
| Status | Legacy; still runs on IIS | Actively developed |
The difference that actually matters for uploads
Classic ASP gives you nothing for uploads. The moment a form is
multipart/form-data, Request.Form comes back empty and you are left with a
raw byte array to parse yourself — which is why a whole category of upload components and
scripts exists for it. That is the subject of
the Classic ASP upload tutorial.
ASP.NET does not have that problem. The framework parses the multipart body for you and exposes the uploaded files as objects with a name, a length and a stream. So the hard part in Classic ASP — getting at the bytes at all — simply is not the hard part on ASP.NET.
What ASP.NET does not give you for free is the same list of things Classic ASP lacks: a live progress bar, a multi-file queue with per-file cancel, client-side validation before the transfer starts, and a sane story for very large files. Those are UI and transport concerns, and they are why people look for an uploader component on either platform.
Why "with a progress bar" is the part people search for
On both platforms the reason is the same, and it is worth understanding before you evaluate anything: the server cannot report upload progress to the page. The request has to arrive before your server-side code runs, so by the time you could report anything, the upload is finished.
Real progress therefore comes from the browser — XMLHttpRequest upload events
measuring bytes as they leave the machine. Any uploader showing a genuine progress bar is doing this,
whatever the server stack.
The progress-bar guide covers the mechanism in detail; all
of it applies to ASP.NET too.
Which uploader belongs on your stack
Same engine, packaged per platform:
| Your project | Use |
|---|---|
Classic ASP (.asp, VBScript) | ASP Uploader — you are on its site; start at the demos |
ASP.NET Web Forms (.aspx) | AjaxUploader |
| ASP.NET Core / MVC / Razor | CoreUpload |
| Blazor Server or WebAssembly | Blazor Uploader |
| PHP | PHP File Uploader |
| Any backend, plain JavaScript | MultipleUpload |
If you are moving off Classic ASP
A fair number of people searching this way are not choosing a platform — they are migrating off one. Two things are worth knowing before you plan the upload part of that work.
The upload code is not the hard bit. Uploading is a small, well-isolated piece of a Classic ASP application: a form, a handler, and somewhere to put the file. The genuinely painful parts of these migrations are usually session state, COM dependencies, and database access code.
Storage decisions survive the migration; code does not. Where files live, how they are named, and how they are served are decisions that carry over unchanged to any platform. Getting them right now means the migration touches less later:
- Disk or database — the storage trade-off, independent of stack
- Upload security checklist — execute permissions and validation apply to every platform
- Large files and IIS limits —
maxAllowedContentLengthis an IIS setting, so it follows you to ASP.NET
If the Classic ASP application is staying put for now, that is a legitimate choice — plenty of them run for years because rewriting is expensive and risky. It just means you want the upload piece to be something you do not have to think about again.
Frequently asked questions
Is Classic ASP the same as ASP.NET?
No. They share a name and an IIS host and nothing else. Classic ASP runs interpreted VBScript; ASP.NET is a compiled framework. Code does not transfer between them.
Can I use a Classic ASP upload script in an ASP.NET project?
No. It is VBScript in .asp pages. Use the uploader built for your stack — see the
table above.
Why does ASP.NET still need an uploader component?
Because reading the file is the easy part on ASP.NET. The progress bar, the multi-file queue, cancelling a transfer and pre-flight validation are browser-side concerns the framework does not provide.
Skip the plumbing
ASP Uploader does everything on this page out of the box: multi-file selection, a real progress bar, client and server validation, incremental large-file handling, and no COM component to register. Drop the folder on your server and add one include line.