Why an app refuses a file you drag onto it

When you drag something over a window, the app underneath gets asked a question: can you take this? If it answers no, the pointer keeps the file with it and nothing happens when you let go. Nine times out of ten the reason is one of three things: the app does not handle that file type, you are hovering over a part of the window that accepts nothing, or the app is not in a state where it can receive anything.

How a Mac decides whether a drop is allowed

Every drag carries the item in several forms at once. A file dragged from Finder travels as a file reference, a path in plain text, and often a preview image. Every window on screen publishes a list of the forms it is willing to accept. macOS compares the two lists as your pointer moves.

If there is a match, you get feedback: the target highlights, a border appears, an insertion point blinks, or the pointer picks up a green plus badge. If there is no match, you get nothing. That silence is the app saying no, not the system failing. There is more on how those forms work in how to give each app the format it expects.

The important consequence is that a rejection is specific to the exact spot under your pointer at that exact moment. Move two inches and the answer can change.

The five common causes, in the order worth checking

1. You are over the wrong part of the window. Many apps accept drops only in one region. A chat app wants the message area, not the sidebar of conversations. A mail composer wants the body or the attachment bar, not the toolbar. A code editor wants the editor pane or the file tree, not the status bar. Drag slowly across the window and watch for a highlight; that highlight is the real target.

2. The app cannot open that type. An image editor will refuse a spreadsheet. A PDF reader will refuse a video. Nothing is broken; the app simply never registered an interest in that type. Checking is easy: select the file in Finder, press Command-I, and look at the Open with section of the info panel. The menu there lists every app on your Mac that claims the type. If the app you are aiming at is not in that list, dragging will never work.

3. The window is modal or busy. If the app has a sheet or dialog open, even a hidden one behind another window, drops into the main window are usually blocked until you dismiss it. Same if the app is mid-save or showing a progress bar. Click the app to bring it forward, clear whatever is waiting, then try again.

4. The drag came from a place that offers no file. Dragging a selection out of a preview, a web page image, or a managed photo library sometimes hands over a picture or a chunk of text rather than a file on disk. An app expecting a file will refuse a picture even though it looks identical to you. What the pasteboard holds when you copy a file covers the same split.

5. You let go too early or in the wrong order. If you release the trackpad a fraction before the pointer settles, the drag cancels quietly. On a MacBook this happens most often when the drag crosses the whole screen and your finger runs out of trackpad. How to cancel a drag on a Mac before you drop it describes what a deliberate cancel looks like, which is useful for telling the two apart.

Three reliable ways in when the drag will not work

If the app genuinely handles the file but the drop keeps failing, stop fighting it and use another door.

1. Open With from Finder. Right-click the file, choose Open With, and pick the app. This uses the same mechanism as a double-click and bypasses drag entirely. Hold Option and the menu becomes Always Open With, which sets the default for that one file.
2. The app’s own Open dialog. Press Command-O inside the app. If the picker starts in the wrong folder, press Command-Shift-G and paste the file’s path. How to copy a file’s path on a Mac covers getting that path in one step.
3. Hand over the path instead of the file. Terminals, editors and command-line tools often want text, not a file object. Pasting the path into the prompt works when dropping the file does not.

If none of those three work either, the app really does not support the type, and the next step is converting the file rather than retrying the drag.

When the drag fails because the target is not ready

There is a fourth situation that looks like rejection but is not. The app would take the file happily, but you cannot get the file to it: the window is buried, the conversation is not open yet, the upload field is on a page you have not loaded, or the app has not launched. You end up holding a file with nowhere sensible to put it while you go hunting.

That is a good moment to put the file down somewhere that is not the Desktop. Ledge turns the notch at the top of a MacBook screen into a shelf. Drag the file up to the notch and let go, and it waits there. Now you have both hands free to open the right window, scroll to the right conversation, or launch the app. Open the shelf again with Option-Space or by clicking the notch, and drag the item off when the target is ready. On a Mac without a notch the shelf sits at the top center of the screen and behaves the same way.

Ledge also helps with the type mismatch problem, because it hands each destination the representation that destination can use. The same item dropped on a terminal arrives as a path in text, dropped on a chat app becomes an upload, and dropped in Finder moves the file itself. You do not have to work out in advance which form a given window will accept. Files stay on your Mac the whole time; there is no account and nothing is sent anywhere.

Questions

Why does the same file drop fine in one app and not another?

Because each app publishes its own list of accepted types and its own drop regions. A file that one app treats as a first-class document is a type another app never registered an interest in.

Is there a way to force an app to accept a file type it refuses?

Not by dragging harder. If the app cannot read the format, the honest fix is to convert the file into a format it does read, or to use a different app for that file.

The pointer shows a circle with a line through it. What does that mean?

That badge is the explicit no-drop cursor. The app under the pointer has been asked and has declined this particular item, in this particular spot.

Could a permission setting be blocking the drop?

Rarely for ordinary drops. What does depend on permissions is an app typing a path into another app for you, which uses macOS Accessibility. A plain drag between two windows does not need any special permission.