In this article
If you encounter a name such as Studio-Mac.local in a connection list, treat it as a clue to investigate. The name alone does not tell you who owns the computer, which app is communicating, or whether a particular service will accept a connection. Those are separate questions.
Start with the name macOS shows
Open System Settings → General → Sharing and find the local hostname near the bottom. You can read it without enabling File Sharing, Remote Login, or any other service. The computer name appears separately under General → About.
Apple explains that the default local hostname comes from the computer name, with spaces replaced by hyphens and .local appended. A number may be added to resolve a duplicate name on the local network. See Apple's computer name and local hostname guide.
For example, a displayed computer name of “Studio Mac” could correspond to Studio-Mac.local. This is an illustrative name, not a device we discovered. Compare the actual value in Sharing instead of assuming a familiar name belongs to the device you have in mind.
If you only need to identify a device, stop at reading the value. Renaming your Mac is a different task, and turning on sharing is unnecessary for this check.
For a visual walkthrough of that exact menu path, this 58-second video by MDTechVideos was published on September 20, 2026. We checked its instructions against Apple's current guide on October 11. It shows where to read the name; it does not establish device ownership or service availability.
Separate the four things you are looking at
A useful way to read a network record is to keep its layers apart:
| Detail | What it helps identify | What it does not establish |
|---|---|---|
| Computer name | The friendly name shown by macOS | The current network address |
A hostname ending in .local | A name in the local naming scope | Verified ownership or a working service |
| An IPv4 or IPv6 address | An address returned for a host or used by a connection | A unique physical device for every row |
| A service and port | The particular function a client wants to use | That all other services are available |
Apple's Bonjour domain-naming documentation describes the local scope of these names and distinguishes a host name from a service instance name. The document is archived, but that distinction remains useful when reading discovery results.
A printer can advertise a printing service. A Mac can advertise several services. Seeing several names or records therefore does not automatically mean several computers. Likewise, the same friendly name on another network need not identify the same device.
Why .local is different from localhost
The shared word “local” makes these easy to confuse.
localhost is a special name for loopback: the requesting computer itself. The localhost rules in RFC 6761 specify loopback address handling. A development server addressed as localhost from your Mac is therefore a different destination from localhost opened on your phone.
A name such as Studio-Mac.local instead names a host in the local naming scope. Another device may resolve that name to an address it can use to contact the Mac. Whether the wanted service is enabled and reachable still needs checking.
Do not reverse this into a rule that your own .local name can never resolve to loopback. The result depends on the resolver and the machine doing the lookup, as our observation below illustrates.
What one Mac actually returned
On October 11, 2026, we compared two read-only lookups on a Mac running macOS 15.7.5. We read its LocalHostName and called the native address resolver through Python's socket.getaddrinfo for localhost and the Mac's own Bonjour name. We counted distinct returned address strings, not duplicate socket records.
| Lookup from the tested Mac | Distinct addresses returned | Loopback addresses included |
|---|---|---|
localhost | 2, across IPv4 and IPv6 | 2 |
| The same Mac's own Bonjour name | 7, across IPv4 and IPv6 | 2 |
Names and address values are omitted for privacy. We enabled no sharing service, scanned no neighboring devices, and did not test a connection from another computer.
The useful result is the difference between the two sets. Seven returned addresses did not mean seven Macs. The local hostname resolved more broadly on this machine than localhost, while still including loopback results. Your address count may differ because interfaces, configuration and resolver behavior differ.
This test establishes name-resolution output on one host. It does not demonstrate that another device could reach every address, or that any server was listening.
When a name resolves but the connection fails
Record three details before changing anything: the exact name, the app trying to connect, and the service you expect. “The name exists” is a much narrower observation than “file sharing works.”
Apple's Bonjour FAQ explains that discovery records can remain cached after a device disappears, until their lifetime expires. A visible record can therefore outlast the service that advertised it.
Use this practical sequence:
- Confirm the intended device. Compare its own displayed name or ask its owner. A plausible label is not authentication.
- Confirm the relevant service. Check that the device is awake and that the function you want is available. A successful lookup does not turn a service on.
- Check the app's context. A Local Network permission issue is different from an internet-access issue.
- Compare like with like. Keep the same network and client app while testing one change, so the result is interpretable.
Do not use an ARP table as a complete device inventory. It answers a different question about known IPv4 neighbors. A device's private Wi-Fi address is another separate identifier.
The useful conclusion is specific: you found a local name, resolved a set of addresses, or reached a particular service. Keep those observations separate, and an unfamiliar .local entry becomes much easier to investigate.
