WEBLOC File Documentation
Summary
A .webloc file is a macOS Website Location file, a small internet shortcut that stores one web address. You create it by dragging the icon from a browser’s address bar onto the Finder; double-clicking it opens that URL in your default browser. Its MIME type is application/x-webloc. Technically it is an Apple property list with one URL key, so it is plain text you can read in any editor. It is the Mac equivalent of a Windows .url shortcut.
Technical details
| Feature | Value |
|---|---|
| Full name | macOS Website Location (Finder internet shortcut) |
| File extension | .webloc |
| MIME type | application/x-webloc |
| Format type | Apple property list (plist) holding one URL |
| Developer | Apple |
| Introduced | Mac OS X, Safari era (early 2000s); XML-plist form since ~10.4 |
| Underlying format | XML plist, binary plist, or (legacy) HFS resource fork |
| Key content | a single URL key whose value is the address |
| XML text header | <?xml version="1.0" … then <!DOCTYPE plist …> |
| Binary plist header | 62 70 6C 69 73 74 30 30 (bplist00) |
| Handler (macOS) | Finder resolves the file; the URL opens in the default browser |
| Created by | dragging a page/link icon from a browser to the Finder |
| Open standard | No (Apple format; plist itself is documented) |
| Windows/Linux handler | None built in; read the URL as text |
| Related extensions | .url, .desktop, .lnk, .webarchive, .html |
| Specification | Apple property list basics |
What is a .webloc file?
A .webloc file is the macOS form of an “internet location” file: a saved pointer to a web address, not a copy of the page. Apple introduced it in the early Mac OS X / Safari era, and the modern XML form has been standard since roughly Mac OS X 10.4. You create one by dragging the small icon next to the URL in a browser’s address bar, or a link from within a page, out onto the Finder. Double-clicking the result tells the Finder to open the stored address in your default web browser. It is the direct counterpart of the Windows .url shortcut and the Linux .desktop launcher link.
The important practical fact is that a .webloc holds only a URL. There is no page content, no offline copy, nothing to recover beyond the single link. That is why the cross-platform way to deal with one is to read the address out of the file rather than to install special software.
The plist payload: one URL key
Technically a .webloc is an Apple property list (plist), the same key/value serialization macOS uses for preferences and metadata. Modern files are the human-readable XML flavour: an XML declaration, a plist DOCTYPE, and a single <dict> whose only entry is a URL key. The whole meaningful content of the file is that one string.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>URL</key>
<string>https://www.example.com/page</string>
</dict>
</plist>Some .webloc files, particularly those produced by dragging rather than by an explicit save, are stored as a binary plist instead. Those begin with the eight ASCII bytes bplist00 (62 70 6C 69 73 74 30 30) and pack the same URL key in Apple’s compact binary encoding. macOS reads both transparently; on another OS a binary plist is not human-readable, but the plutil -convert xml1 tool (or any plist library) turns it back into the XML form above.
The resource-fork history and 0-byte files
The earliest Mac OS X versions did not store the URL in the file’s body at all. They kept it in the file’s HFS resource fork, a second data stream that the classic Mac filesystem attached to a file alongside its main “data fork”. On a Mac this was invisible and worked fine, but resource forks do not survive a copy to a Windows or Linux filesystem, a FAT/exFAT USB stick, or most ZIP archives, which only carry the data fork. The result is the classic complaint: a .webloc copied off an old Mac shows up as a 0-byte file with the address gone, because the URL lived in the fork that was stripped in transit.
Modern XML and binary .webloc files keep the URL in the data fork, so they travel intact. If you meet an empty .webloc, it is almost certainly one of these legacy resource-fork files, and the address cannot be recovered from the transferred copy; you would need the original Mac file.
Reading the URL on Windows or Linux
Neither Windows nor Linux has a built-in handler for .webloc, but because a modern one is plain text, you do not need one. Open the file in Notepad, Notepad++, VS Code or any text editor and look for the line inside <string>…</string>; that is the address. Copy it into a browser and you are done. Renaming the file to .txt makes editors open it without complaint. On iOS and iPadOS a .webloc works natively: tapping it opens the URL in the default browser, the same behaviour as on the Mac.
The one case this does not cover is a binary (bplist00) file on a non-Mac system, where the text is not directly legible. There the address is still present, just encoded; a plist viewer or a short script using a plist library extracts it.
Turning shortcuts into .url or an HTML bookmarks page
A .webloc and a Windows .url file are equivalent internet shortcuts, so converting is a matter of moving the address into the other container. A .url is itself a tiny text file: two lines, [InternetShortcut] and URL=https://…, saved with a .url extension. Read the address out of the .webloc, write those two lines, and Windows treats the result as a native double-click shortcut. A short script can batch-convert an entire folder of dragged shortcuts.
If you have a pile of .webloc files and want them in a browser, emit an HTML page instead: one <a href="…"> per address. Every major browser imports an HTML bookmarks file, so this is the clean way to fold a Mac Desktop full of shortcuts into your bookmarks. Converting a .webloc to PDF is meaningless, since the file has no page content; to save the page itself, open the URL and use the browser’s Print → Save as PDF.
References
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.