Technically, it's not possible to decode the input data without the ABI. Your ABI specified what data and data type in encoded in the function parameters. That said, you might have seen etherscan/bscscan with decoded input parameters. Thanks to sources like https://www.4byte.directory/, we have a list of known function signatures and their parameter types. These block explorers likely use something similar to decode known functions. So if the function call you are trying to decode is known in the signature database, you can technically decode it. For example, lets say the input data is 0x2e1a7d4d0000000000000000000000000000000000000000000000000038d7ea4c680000.
In that, the first 4 bytes are the function signature - 0x2e1a7d4. The remaining are input parameters.
We could then lookup in https://www.4byte.directory/ for the signature (link). It says the function is withdraw(uint256).
Now that we have the function definition, we can easily decode the input. You can do it via libraries like web3 or ethers, or some web tools to do the same. In this case, the input is 0x38d7ea4c680000 which is the hex for 16000000000000000. So the function call was withdraw(16000000000000000).
But like said, this worked only because the function signature of withdraw(256) was known. If it's a new function signature that is not previously known, it's impossible to decode the input. You can read more about how input is encoded here.
