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 neededNoYes — regsvr32NoNo
Works on shared hostingYesRarelyYesYes
Multiple file selectionYou build itUsuallyRarelyYes
Progress barNoSometimesNoYes
Cancel in progressNoSometimesNoYes
Practical large-file ceilingRAM-boundGoodRAM-boundChunked — effectively unbounded
Client-side validationNoNoNoYes
CostYour timePer-server licenceFreePer-developer licence
MaintainedBy youVariesUsually abandonedYes

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 hadYou now have
Server.CreateObject("...Upload")new AspUploader after one include
upl.Save pathuploader.SaveDirectory, or mvcfile.MoveTo
Iterating upl.FilesSplitting the posted GUID list, then GetUploadedFile()
file.OriginalPathmvcfile.FileName
file.Sizemvcfile.FileSize
Component size limit settinguploader.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.

Download the free trial Try the live demo Pricing