It's unclear from the question whether you want to connect to a device for the first time based on MAC address (perhaps the user is opening your application on a new phone but already has a device associated with their account) or if you want to reconnect to a device the user has selected before.

Web Bluetooth always requires user interaction before a site's first connection to a device. The requestDevice() method takes a filter parameter which can be used to limit the set of devices the user is asked to choose between. It currently does not support filtering on MAC address.

The specification also includes an extension to the Permissions API's query() method which allows a site to reconnect to devices it previously had permission to access. Chrome does not currently implement this method. Work to do so is tracked by issue 577953.

Can you explain more about how your app works so I can understand which of these solutions you are asking for?

Thanks for your quick response. Let me explain clearly what I'm trying to achieve.
There are some BLE devices whose mac addresses are known to me. When a user requests, the server will assign a BLE device to that user only for once and will send its mac address. Now the user should be able to connect to that device without asking to choose from the list of devices by using the mac address which will be sent by the server.
In my android app I achieved it by
remoteDevice = btAdapter.getRemoteDevice("xx:xx:xx:xx:xx:xx");
remoteDevice.connectGatt(getActivity(), false, mGattCallback);

Is there any way I can achieve it using web bluetooth api's ?

There are no plans to allow a page to get access to a device by MAC address without asking the user for permission the way that the Android API allows. We can however consider adding the MAC address as a filterable device property so that it is the only device available for the user to select (assuming that it is in range and appears at all).

If I can also add one comment here, on Mac OS, Corebluetooth API doesn't provide MAC address. We can infer the information from CoreBluetoothCache entry in /Library/Preferences/com.bluetooth.apple.plist, but the entry is created if device has been connected at least once if I'm right.

Reason being probably that if device uses a "private resolvable random address", address will change frequently so that device cannot be used for tracking.

I think the fact that macOS does not provide the true MAC address was a reason for not supporting it as a filter. I'm willing to support it on platforms where the true MAC address is available and for devices that do not broadcast randomized addresses. The better solution is the persistent device permission work mentioned above which can utilize privacy-preserving mechanisms such as the Identity Resolving Key to recognize when a previously connected device is once again within range.

Is there any ongoing plan to use mac address as a filter ?

As it relates to this issue, we do have access to the MAC address on MAC OS when using Chrome and WebBLE? Based on my test, this hold true for MAC OS, Windows 10 and Chromebook. Apple does not support MAC addresses in their Mobile OS. However, WebBLE is not supported on IOS anyway. So in this case, adding the filter would be more than suitable for those that are truly using WebBLE on supported platforms, right?

There are many use cases where you simply want to connect to a specific device. In the case where users are working in a group environment, using the same hardware, it's nearly impossible to attach to the correct device if they are broadcasting at the same time with the current options.

The MAC addresses Chrome displays for devices on macOS are artificial. If you compare them to what is displayed on other platforms you will find they do not match. The macOS Bluetooth API only provides a UUID to represent the device, not the MAC address.

That's for the clarity. I didn't realize it was fake at first glance. I was just happy to see numbers :). So using the manufacturer filter would be the best option long term. Hopefully that stabilizes soon.

I too think using manufacturer filter would be the best option.