VBA Delete File in Excel — Kill, FileSystemObject.DeleteFile, and Why There Is No Undo

TL;DR — Kill path deletes a file permanently. There is no Recycle Bin, no confirmation, and no undo — a Kill is closer to a shredder than to dragging a file to the trash. It also errors rather than doing nothing if the file is missing or open, so the safe pattern always checks first:

Sub DeleteTempFile()
    Dim path As String
    path = "C:\Reports\~temp.xlsx"
    If Dir(path) <> "" Then Kill path      ' only Kill what actually exists — and it is gone for good
End Sub

After a macro has copied or processed its files, the last step is often to clean up — delete the temp file, clear out yesterday's exports. Kill is the built-in that does it, and it is genuinely dangerous in a way FileCopy is not: there is no getting the file back. Everything worth knowing about Kill is a rule for staying on the right side of that one-way door.

What you'll learn

The mental model — Kill is permanent deletion, not "move to Recycle Bin"
Why Kill errors on a missing or open file instead of silently doing nothing
How a wildcard deletes many files at once — powerful, and unforgiving of typos
Why Kill cannot delete a folder, and how RmDir and DeleteFolder divide that job
When FileSystemObject.DeleteFile with its Force flag beats Kill on read-only files
The safe deletion pattern — check, then delete, and archive first when in doubt

The mental model: Kill is permanent, not the Recycle Bin

The single most important thing about Kill is what it does not do: it does not move the file to the Recycle Bin. When you delete a file in File Explorer, Windows quietly keeps a copy you can restore. Kill bypasses all of that. The file is unlinked from the disk immediately and there is no supported way to get it back from VBA.

Treat Kill the way a Unix admin treats rm — as an irreversible operation you point carefully and fire deliberately. That framing drives every rule below. If a file might still be needed, the right move is not a cleverer Kill; it is to copy it to an archive before you delete the original.

Kill errors on a missing or open file — it does not no-op

A surprising number of people assume Kill on a non-existent file just does nothing. It does not — it raises a run-time error:

Kill "C:\Reports\does-not-exist.xlsx"   ' error 53 — "File not found"
Kill "C:\Reports\open-book.xlsx"        ' error 70 — "Permission denied" (file is open/locked)

error 53 — the file is not there. Guard with an existence test before you call Kill.
error 70 — the file is open, read-only, or locked by another process. You cannot Kill a workbook that is open in Excel; Close it first.

So the canonical delete is a two-part guard: test that the file exists with Dir(path) <> "" for the common "not there" case, and wrap the call in On Error for the rarer locked case — because a file can pass the existence test and still be locked a millisecond later:

If Dir(path) <> "" Then
    On Error Resume Next          ' handle the locked-file case explicitly
    Kill path
    If Err.Number <> 0 Then MsgBox "Could not delete: " & path & " (" & Err.Description & ")"
    On Error GoTo 0
End If

Note the difference from copying: here On Error is a deliberate handler for a known, rare failure, not a blanket suppressant. Blindly wrapping every Kill in On Error Resume Next with no Err check is how cleanup silently stops happening.

Wildcards delete many files at once — with no prompt

Kill accepts the same * and ? wildcards as Dir, and it applies them to every match in a single statement:

Kill "C:\Reports\Temp\*.tmp"     ' deletes EVERY .tmp in that folder — no prompt, no undo

This is enormously useful for cleanup and genuinely hazardous. There is no confirmation, so a typo in the pattern — *.xls* when you meant *.tmp, or the wrong folder — erases far more than you intended, instantly and permanently. Two safety habits:

Read before you delete. If the pattern is at all dynamic, loop it with Dir first and Debug.Print or log every name that would be deleted, then delete on a second pass.
Never build the path from unchecked input. A blank variable turns Kill folder & "\*.*" into Kill "\*.*" — pointed at the wrong place entirely.

One subtlety with wildcards and looping: you cannot safely run a Dir enumeration and Kill matches inside the same loop, because deleting files mutates the folder the Dir cursor is walking. Collect the names into an array first, then delete — the two-pass pattern from the Dir guide.

Kill deletes files, not folders — RmDir and DeleteFolder

Kill removes files. Point it at a folder and you get error 5 (invalid procedure call). Folders are a different set of tools, and they split by whether the folder is empty:

RmDir path — removes an empty folder only. If anything is still inside it, error 75. So the built-in way to delete a folder is: Kill its contents (or the matching files), then RmDir the folder.
fso.DeleteFolder path — the FileSystemObject version removes a folder and everything in it, recursively, in one call. This is the tool when you need to wipe a whole tree — and, like Kill, it does not use the Recycle Bin.

Mixing these up is common: people try Kill "C:\OldExports" to remove a folder and are surprised by the error. Files use Kill; empty folders use RmDir; full trees use fso.DeleteFolder.

FileSystemObject.DeleteFile: the Force flag for read-only files

Kill refuses to delete a read-only file — it raises error 70, the same permission error as an open file. The FileSystemObject gives you a cleaner tool with an explicit override:

Dim fso As Object
Set fso = CreateObject("Scripting.FileSystemObject")   ' late binding — runs on any machine
If fso.FileExists(path) Then fso.DeleteFile path, True  ' Force:=True deletes read-only files too

DeleteFile also pairs with fso.FileExists for a stateless existence check that never disturbs a Dir loop, and it accepts wildcards like Kill. Reach for it when you are already using the FileSystemObject for the rest of the job, or specifically when read-only files are in play — but respect that Force:=True is more dangerous than Kill, not less: it deletes files someone deliberately protected.

The honest verdict: check, then delete — and archive when unsure

Kill is the right tool for cleanup, and it demands more respect than any other file statement precisely because it cannot be undone. Four rules:

Guard existence — If Dir(path) <> "" Then Kill path, so a missing file is a no-op, not error 53.
Handle the locked case — wrap Kill in a real On Error handler with an Err check for the open or read-only file; do not blanket-suppress.
Treat wildcards as live ammunition — read (or log) the matches before a dynamic Kill *.*, and collect-then-delete rather than deleting inside a Dir loop.
Archive before you delete anything you might want back — a FileCopy to an archive folder is cheap; recovering a Killed file is impossible.

When you are not certain a file is disposable, do not delete it — copy it aside first. Kill has no undo, so you are the undo.

How ExcelMaster helps

Deleting files safely means guarding existence, handling the locked-file case without silencing real errors, respecting wildcards that erase many files at once, and knowing that folders need RmDir or DeleteFolder rather than Kill — a lot of caution to wrap around one irreversible statement.

ExcelMaster writes the safe version. Describe the cleanup — "delete every temp file in this folder after the export" or "remove last month's archive folder" — and it produces the guarded Kill with the existence check and error handler, the collect-then-delete loop when files are enumerated, the RmDir/DeleteFolder split for folders, and an archive copy first when the files might still be needed. You describe the outcome; it keeps the one-way door from catching you.

Frequently asked questions

How do I delete a file in VBA?

Use the built-in Kill path — for example Kill "C:\Reports\temp.xlsx". Guard it with an existence test first, If Dir(path) <> "" Then Kill path, because Kill raises error 53 on a file that does not exist rather than doing nothing. Remember that Kill deletes permanently — there is no Recycle Bin and no undo — so copy anything you might need to an archive before deleting it.

Does VBA Kill move the file to the Recycle Bin?

No. Kill deletes the file immediately and permanently; it does not go to the Recycle Bin and there is no supported way to recover it from VBA. This is different from deleting in File Explorer, which keeps a restorable copy. If you need trash-bin behaviour you must call the Windows Shell API — otherwise treat every Kill as final and archive first when in doubt.

Why does VBA Kill give error 70 or error 53?

error 53 (File not found) means the file does not exist — guard with If Dir(path) <> "" Then before you Kill. error 70 (Permission denied) means the file is open, read-only, or locked by another process — close any open workbook first, and for read-only files use fso.DeleteFile path, True with the Force flag. Kill errors in these cases rather than silently doing nothing.

How do I delete multiple files with a wildcard in VBA?

Kill accepts wildcards, so Kill "C:\Temp\*.tmp" deletes every .tmp file in that folder in one statement — with no prompt and no undo. Because there is no confirmation, log the matches with a Dir loop first if the pattern is dynamic, and never delete inside a Dir loop (collect the names into an array, then delete) since deleting mutates the folder the cursor is walking.

How do I delete a folder in VBA?

Kill deletes files, not folders. To remove an empty folder use RmDir path; if it still has contents, Kill those first, then RmDir. To delete a folder and everything inside it in one call, use the FileSystemObject: fso.DeleteFolder path, which removes the whole tree recursively. Like Kill, neither uses the Recycle Bin.

Tested in

Tested in: Excel 365 (Windows 11), VBA 7.1 — last verified 2026-08-22.