I've been working on a side project to see how far a serious HTTP client can be pushed inside Excel/VBA.
It started with a fairly simple thought:
Maybe I can build something nicer than the usual thin wrapper around WinHttpRequest.
It escalated quite a bit from there.
The result is VBA-HTTP, an HTTP client for Windows written in VBA:
https://github.com/harumiWeb/VBA-HTTP
It covers the usual things you'd expect from an HTTP client — requests and responses, headers, query parameters, and text/binary bodies — but I wanted to push it quite a bit further.
Some of the more unusual parts are:
- bounded concurrent requests
- a native
winhttp.dll backend in addition to WinHttp.WinHttpRequest.5.1
- streaming multi-GB downloads and uploads without buffering the entire payload in VBA memory
- streaming multipart uploads
- retries with exponential backoff, jitter, and
Retry-After
- deadlines and cancellation
- Basic, Bearer, and Windows challenge authentication
- proxy support and an explicit cookie jar
- HTTP/2 protocol control and reporting through native WinHTTP
- deterministic WinHTTP handle and resource cleanup
The API is intended to feel more like an HTTP client from a modern language than a collection of raw COM calls.
Dim client As HttpClient
Dim request As HttpRequest
Dim response As HttpResponse
Set client = VBAHttp.CreateClient()
Set request = VBAHttp.CreateRequest()
request.Method = "GET"
request.Url = "https://example.com/items"
request.Query.Add "page", 1
request.Query.Add "limit", 100
Set response = client.Execute(request)
response.RaiseForStatus
Debug.Print response.Text
It also supports bounded concurrency across multiple independent requests:
Dim urls As New Collection
Dim options As New HttpBatchOptions
Dim result As HttpBatchResult
urls.Add "https://example.com/a"
urls.Add "https://example.com/b"
urls.Add "https://example.com/c"
options.MaxConcurrency = 8
Set result = client.GetMany(urls, options)
Debug.Print result.SuccessCount
Debug.Print result.FailureCount
For example, against a deterministic local test server where each of 100 requests waits for 100 ms:
Sequential 11.04 s
Concurrency 16 0.86 s
12.86x faster
Obviously this is a deliberately latency-heavy benchmark. I'm not claiming that every HTTP workload becomes 12.86x faster.
The benchmark methodology and raw results are included in the repository.
Large transfers were another area I wanted to push.
VBA-HTTP can stream a 1 GiB download without representing the entire payload as a 1 GiB VBA Byte() array.
In one recorded x64 Excel baseline run, the transfer showed approximately 19 MB of peak private-memory growth.
It can also stream 1 GiB file uploads and multipart uploads incrementally through native WinHTTP.
More recently I've also been optimizing the native hot path itself — reusing fixed buffers, reading directly with WinHttpReadData, pre-sizing known-length buffered responses, and removing VBA byte-by-byte copies.
I deliberately stopped short of things like generated machine code or executable-memory tricks.
The native implementation only uses documented Windows APIs. I still want this to be something people could reasonably use, rather than just a VBA black-magic demo.
The other thing I wanted to push: testing
I didn't want the verification story for this project to be:
"It works on my machine."
The repository has automated unit, integration, stress, resource, and release-validation tests, running against real Excel and a deterministic local HTTP/HTTPS server.
Among other things, the test suite exercises:
- 1 GiB download and upload with content/hash verification
- a 10,000-request resource and WinHTTP handle stability run
- repeated cancellation and timeout cleanup
- bounded-concurrency behavior
- retry and
Retry-After behavior
- proxy and authentication fixtures
- HTTP/2 capability and negotiated-protocol validation
- release checksum and tamper validation
- real VBE compilation
A lot of VBA libraries understandably rely heavily on example workbooks and manual verification.
For this project, I wanted the behavior to be reproducible and machine-verifiable in roughly the same way I'd expect from a library in another language.
And there's one other slightly unusual part of the project:
I didn't manually write a single line of the implementation code.
I designed the architecture, requirements, acceptance criteria, benchmarks, and overall direction, but the implementation itself was written by coding agents operating through xlflow, the VBA development environment I've been building.
The agents worked on normal VBA source files, ran static analysis, compiled the project in real Excel, executed tests, inspected failures, modified the implementation, and repeated that feedback loop.
At one point I was literally away on vacation while the agent workflow continued building out the project.
About xlflow:
https://github.com/harumiWeb/xlflow
I originally built xlflow because I wanted coding agents working on VBA to have the same kind of:
edit → compile → test → analyze → fix
feedback loop that they get in more modern ecosystems.
VBA-HTTP ended up becoming a much more demanding dogfooding project than I originally expected.
So the project effectively became two experiments at once:
- How far can networking and performance be pushed in VBA while keeping the result reasonably practical?
- How complex a VBA project can coding agents build if they're given proper engineering feedback loops?
I'd be interested in feedback on either side.
And if anyone tries VBA-HTTP against a real API, corporate proxy, authentication setup, or weird HTTP server and manages to break it, I'd especially like to hear about it.