Modern cryptography operates mostly on binary values or big numbers. And generally cryptography that operates on numbers encodes / decodes those numbers to binary as well (RSA PKCS#1 specifies binary representations for the public key, private key and of course the ciphertext and signatures). If an API specifies text input / output it is generally provided as a convenience to the programmer rather than that it is part of the implemented algorithm specification.
To have printable ASCII it is easiest to convert the binary value generated by your KDF to base64 or base64url. In that case each character encodes 6 bits. It should be easy to calculate the output size of the KDF to give the precise amount of base 64 characters. Otherwise you could still cut of the left over base 64 characters, but remember that base 64 implementations may require you to input 4 characters at a time (including padding characters) making it impossible to decode your pruned base 64 encoding directly. It would make sense to use a multiple of 3 for the output of the KDF / multiple of 4 characters after encoding using base 64.
To have base 62 (as specified in your question) is much harder, as 62 is not a power of two. That means that you either need to perform base conversion using big integer calculations (divide-and-remainder) or you'll have to convert to base64 and escape out three characters (the
/ and the escape character itself). Escaping will result in a variable length encoding though, maxing out on doubling the base64 string in size.
- Hexadecimals is even easier to work with: it takes 2 characters per byte, and that's it. It will expand the output some more, but that may be worth it for the convenience it offers;
- Encoding keying material in a textual string is generally frowned upon. Strings are easy to find in application code and are generally hard to destroy (e.g. Java has immutable strings that may not be garbage collected either).