Classic ASP File Upload Methods Compared
Four ways to accept a file in Classic ASP, and the trade-off each one makes.
There are four realistic ways to accept a file in Classic ASP. They differ less in what they can do than in what they cost you — in server access, in maintenance, and in the size of file you can survive.
The comparison
| Hand-written BinaryRead | COM component | Free ASP class | Pure ASP uploader | |
|---|---|---|---|---|
| Server admin needed | No | Yes — regsvr32 | No | No |
| Works on shared hosting | Yes | Rarely | Yes | Yes |
| Multiple file selection | You build it | Usually | Rarely | Yes |
| Progress bar | No | Sometimes | No | Yes |
| Cancel in progress | No | Sometimes | No | Yes |
| Practical large-file ceiling | RAM-bound | Good | RAM-bound | Chunked — effectively unbounded |
| Client-side validation | No | No | No | Yes |
| Cost | Your time | Per-server licence | Free | Per-developer licence |
| Maintained | By you | Varies | Usually abandoned | Yes |
1. Parse Request.BinaryRead yourself
What it is: read the raw body, find the MIME boundary, slice out each part, write the
bytes with ADODB.Stream.
Good for: a single small file on a server you cannot touch, where adding a dependency is not worth it. An avatar uploader in an admin page.
Bad for: everything else. The whole post sits in memory, there is no progress, no cancel, no multi-select, and binary-safe string handling in VBScript is a genuine source of subtle corruption bugs — the kind that only show up on certain file types.
<%
Dim binData
binData = Request.BinaryRead(Request.TotalBytes) ' entire post, in RAM
' ...then find the boundary, parse headers, MidB out the payload...
%>
2. A registered COM component
Examples: ASPUpload, SA-FileUp, AspSmartUpload, ABCUpload.
Good for: a dedicated server you control, where raw throughput matters and the licence is already paid for. Compiled parsing is genuinely faster per byte.
Bad for: shared hosting (they will not register it), source-controlled deployment (the DLL lives outside your site), and migrations. Add the 32-bit/64-bit app pool trap and the per-server licence cost for staging boxes.
<%
Dim upl
Set upl = Server.CreateObject("Persits.Upload") ' fails with 800700c1 on a bitness mismatch
upl.Save Server.MapPath("uploads")
%>
3. A free ASP upload class
Examples: the various "Pure ASP File Upload" scripts circulating since the early 2000s.
Good for: a prototype, or a low-traffic internal page where nothing large is uploaded and nobody is hostile.
Bad for: production. These are typically single-file, in-memory parsers written when IE6 was current, unmaintained for a decade or more, with no client-side validation and no chunking. They inherit every limitation of option 1 — you just did not write the bug yourself.
4. A maintained pure ASP uploader
Example: ASP Uploader.
What it is: plain .asp and JavaScript files you copy into the site.
Nothing to register, nothing for the visitor to install.
<%@ Language="VBScript" %>
<!-- #include file="aspuploader/include_aspuploader.asp" -->
<form id="form1" method="POST">
<%
Dim uploader
Set uploader = new AspUploader
uploader.Name = "myuploader"
uploader.MultipleFilesUpload = true
uploader.MaxSizeKB = 10240
uploader.AllowedFileExtensions = "*.jpg,*.png,*.gif,*.zip"
%>
<%= uploader.GetString() %>
</form>
Good for: anything user-facing. Chunked transfer means large files do not depend on RAM; the queue, progress bar, cancel button and client-side validation are the parts you would otherwise spend weeks building and never quite finish.
Trade-off: it is commercial software, and script parsing is slower per byte than a compiled component — a difference chunking makes largely academic, since the server never handles more than one chunk at a time.
How to choose in thirty seconds
- One small file, admin-only page, server you cannot change → hand-written parse.
- Dedicated server, licence already bought, throughput is king → COM component.
- Prototype you will throw away → free class.
- Real users, shared hosting, big files, or you need a progress bar → pure ASP uploader.
One question settles it more often than any other: can you run regsvr32 on the
production server? If the answer is no — and on shared hosting it always is — two of
the four options disappear immediately.
Migrating from a COM component
The change is smaller than it looks, because the shape of the work is the same: render an upload control, then loop the received files.
| You had | You now have |
|---|---|
Server.CreateObject("...Upload") | new AspUploader after one include |
upl.Save path | uploader.SaveDirectory, or mvcfile.MoveTo |
Iterating upl.Files | Splitting the posted GUID list, then GetUploadedFile() |
file.OriginalPath | mvcfile.FileName |
file.Size | mvcfile.FileSize |
| Component size limit setting | uploader.MaxSizeKB (enforced in the browser too) |
The form itself changes: drop enctype="multipart/form-data" and the
<input type="file">, because GetString() renders the control and the
file travels on its own request.
Frequently asked questions
What is the best file upload component for Classic ASP?
It depends on server access. Without administrator rights a pure ASP script is the only option that also gives you progress, multi-select and large-file support.
Is ASPUpload still supported?
Commercial COM components vary in how actively they are maintained; check the vendor before committing. The bigger question is whether your host will register anything at all.
Can I use a free ASP upload script in production?
You can, but understand what you are accepting: unmaintained code, in-memory parsing, and no client-side validation. Read the security checklist first.
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, chunked large-file transfer, and no COM component to register. Drop the folder on your server and add one include line.