Encoding, hashing, and IDs do different jobs
Several tools produce unfamiliar-looking strings. Their appearance can be similar while their jobs are completely different. Start with the problem you need to solve.
Use encoding to change representation
Base64 turns bytes into a text-friendly alphabet. URL component encoding escapes characters that could otherwise be mistaken for URL structure. Both are reversible representations. Neither is a secret-keeping system. If you can decode a value without a key, another person with that value can generally do the same. Do not send confidential information merely because the encoded form is harder to read at a glance.
Match the encoding to the channel
For a URL query value containing an ampersand, use component encoding so the ampersand is not interpreted as the next parameter separator. For a text channel that explicitly expects Base64, use the requested Base64 alphabet. Standard and URL-safe Base64 differ in a few characters and in common padding conventions. A correct encoding for one channel can be the wrong format for another; read the receiving API’s examples.
Use a digest to compare exact content
A SHA-256 hash is a digest of the input bytes. In Daykit text mode, those bytes are UTF-8. Adding a space or changing a line ending can produce a different digest. For files, renaming a byte-identical file does not change its digest. Compare the complete result with a trustworthy expected value. If the reference is untrusted, a match does not establish that a download is safe or authentic.
Use an identifier to name a record
A random UUID v4 is useful as an identifier in a prototype or database design. It is not a centrally registered certificate and it does not prove that a record belongs to the person who presents it. Applications still need uniqueness checks and access controls. A link with an obscure UUID can still be shared, logged, or discovered through another part of a system.
Use a password for the role of a secret
A fresh password should match the receiving service’s requirements and be stored in a trusted password manager. Do not substitute a public identifier for an authentication secret. Likewise, a plain SHA-256 utility is not a complete password-storage design. Credential storage needs a design appropriate to that purpose; this guide does not turn a collection of text utilities into an authentication system.
Keep a simple decision question
Ask: am I changing how data is written, comparing exact data, naming a record, or creating a login secret? Choose the tool that answers that question. Keep test values separate from real credentials, verify the expected input unit or alphabet, and check the output in the receiving application. The right distinction is more useful than memorizing the shape of a generated string.
Read the editorial & corrections policy for the scope of our checks and authorship.