A byte is 8 bits; 10 random bytes are therefore 80 random bits, which is $2^{80}$ equiprobable alternatives (not $2^{40}$), which is 80 bits of entropy. (Unless your 10 byte random string is actually an ASCII representation of a 40-bit hexadecimal value; since SecureRandom
outputs full range byte[]
I'll assume it's not that.)
This secret is encoded afterwards (e.g. Base64). This is supposed to reduce entropy, while extending the string length.
This "entropy reduction" isn't real. Any Base64 encoder is a one-to-one function—each of the $2^{80}$ inputs in your example is mapped to a unique output. There are therefore $2^{80}$ unique possible outcomes as well, each one equally likely, and thus 80 bits of entropy like originally.
What's probably confusing you is that the binary representation of the Base64-encoded string is longer than 80 bits, but it's not made of uniform random bits, so in that sense it's not a full-entropy string—the 14-ish bytes in the Base64 string are 112 bits long but would only collectively have 80 bits of entropy.
If I want to brute force the secret, does the encoding has any negative impact on the protection?
Not really. Again, $2^{80}$ possible outcomes, all of them equally likely.