Pure ASP File Upload Without Installing Server Components

Classic ASP guide · Updated 2026-08-16

Shared hosting will not let you regsvr32 anything. Here is how pure ASP upload code solves that.

The problem with registering a component

For most of Classic ASP's life, accepting a file meant buying a compiled upload component and running regsvr32 on the web server. That works beautifully — when you own the server. When you do not, it falls apart in familiar ways:

• Shared hosting says no. A host that lets arbitrary customers register DLLs into the server's COM registry has effectively given every customer the machine. Almost none allow it.
• Registration is invisible state. The DLL lives outside your site folder, so it is not in source control, not in your deployment, and not in the backup you restore from at 2 a.m.
• Bitness bites. A 32-bit component needs the app pool set to Enable 32-Bit Applications. Forget that and you get Server.CreateObject Failed — 800700c1 with no useful clue.
• Licensing is per-server. Dev box, staging box, production box, DR box — that is four licences of something you use in one page.

What "pure ASP" actually means

A pure ASP upload script is written in the same VBScript/JScript your pages are written in, plus client-side JavaScript. It uses only objects that ship with Windows and IIS:

Every one of those is already enabled on any host that can run Classic ASP at all. Deployment is therefore an FTP copy, and moving servers is another FTP copy.

Installing a pure ASP uploader

The whole install for ASP Uploader is: copy the aspuploader folder into your site, then include it in the page that needs it.

<%@ 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.SaveDirectory = "savefiles"
    uploader.Render()
    %>
</form>

That is the entire server-side setup. There is no Server.CreateObject call to fail, no registry key to be missing, and no 32-bit/64-bit mismatch to debug.

The only thing you do have to configure

Two folders need write access from the application pool identity:

• The temp folder the uploader streams incoming bytes into.
• The destination folder you finally move files to.

On IIS 7 and later the identity is normally IIS AppPool\<YourAppPoolName>. Grant it Modify on those two folders and nothing else. From an elevated prompt:

icacls "C:\inetpub\wwwroot\mysite\uploads" /grant "IIS AppPool\DefaultAppPool":(OI)(CI)M

Where pure ASP is genuinely worse

Being honest about it: VBScript is slower than compiled C++ at byte-shuffling. If your upload path is a hand-written Request.BinaryRead parser, a component will beat it on CPU for large files.

The way around this is not to make the parser faster — it is to stop pushing whole files through it. A chunked uploader splits the file in the browser and sends fixed-size pieces, so the server never holds more than one chunk and CPU cost stays flat regardless of file size. That is why a pure ASP script can handle multi-gigabyte uploads that would kill a naive in-memory parse. See uploading large files in Classic ASP.

Pure ASP vs. COM component at a glance

Frequently asked questions

Does a pure ASP uploader need write access to the registry?

No. It touches nothing outside your site folder except the temp and destination folders you nominate.

Will it work on GoDaddy, Ionos or another shared Windows host?

Yes, provided Classic ASP is enabled and you can grant write permission to an upload folder — which shared control panels normally expose as a per-folder setting.

Can I use it on a 64-bit application pool?

Yes. Script has no bitness, so the 32-bit/64-bit problem that plagues COM components does not exist here.