Many wallet software obfuscate the information about payment and change address in order to protect the privacy of the user. When you see block explorer websites showing addresses in the outputs as change addresses, they are merely guessing as there is no sure shot way of knowing. Some of the techniques used to identify change addresses are below. I have also mentioned the current steps taken to prevent detection of such change addresses.

• Sending change back to the same address: If you send the change back to the same address from which you are initiating the transaction, then there is high likelihood of that address being a change address. This is mitigated by preventing address re-use.
• Change goes back to the same address type: If you initiated a transaction from a native segwit address (addresses starting with bc1) to a P2SH address (starting with 3). In some wallets, the change will be sent to the native segwit (bc1) address as that is the default for your wallet, thus leaking which output is the change. This is prevented by making the change address match the format of the payout address in order to mask privacy.
• Coin selection: Assume you want to make a payment of 5 BTC for your coffee (let's hope that the coffee is that good :-)). Your wallet contains two UTXOs: 4 BTC and 3 BTC. To make a payment of 5 BTC, you will have to use both UTXOs and send 2 BTC change back to yourself. Now, the person looking at this transaction would think that if you wanted to make a 2 BTC payment you would have just used your 3 BTC output and sent 1 BTC as change as compared to using both the UTXOs. Thus it is revealed that the 2 BTC is in fact a change output rather than a payment output. Wallet softwares might create two or more change addresses in order to mask which is exactly the change address, or if multiple UTXOs exist, it will optimally select those UTXOs in order to prevent such leak.
• Change address is the last output: If you build your transaction in such a way that your payment addresses comes first and change comes last, then it reveals which of the output is a change. For example, Bitcoin Core had a bug years ago, where it would never put change first despite randomization, which for single-payment transactions resulted in a deterministic position of change address (second). To prevent such deterministic ordering of change address in outputs, BIP 69 recommends lexicographical ordering of inputs and outputs. Outputs are arranged in ascending order of the amounts, followed by the scriptPubKey.