What you are doing is not "encryption", per se; it's "hashing". The principal difference between the two is that encryption is easily reversible (with the correct key of course), while hashing is designed to be extremely difficult to reverse in any circumstance other than knowing the original message in the first place.
In theory, hashes simulate a "random oracle", a hypothetical homunculus with an eidetic memory and a way to generate perfectly unique, perfectly random numbers with no upper range limit. You'd give this little man a message, and one of two things would happen; either he's never seen the message before, in which case he generates a new random number and gives that to you as the digest, or he has seen that messsage before, and so he remembers and gives you the number he generated when he saw it the first time. In that theoretical model, there is zero relationship between a message and its digest, and with no single number ever appearing twice from the RNG there's no possibility for a collision.
Unfortunately, we don't have an ideal random oracle; the idea has practical impossibilities for a digital implementation, such as the ability of the oracle to efficiently store and efficiently recall every message ever hashed by anyone anywhere, and the ability of the clients to accept a number that could be hundreds or thousands of decimal digits in length. Instead, we have hash functions, which are irreversible (one-way) mathematical operations that work on the message itself, to create a deterministic transformation (same message => same hash) with no apparent relationship between the hash and the original message. As mentioned in the comments, there should also be no predictable change to the hash value produced by making systematic changes to the message; ideally, each bit of the digest would have a 50% chance to change, given a change to a single bit of the message.
There are many uses for a hash function; they're used for challenge verification (think login credentials like passwords) without the need for both parties to know the plain text secret, and they're used as checksums to verify that a message hasn't been tampered with or corrupted. They're also used in so-called "proof of work" scenarios; computational tasks that are difficult to complete but easy to verify.
If you were ever to find a way to efficiently reverse a SHA256 hash digest to produce a message (any message) that would result in that hash, it would be a proof by demonstration that in fact the hash is fundamentally broken. SHA256 is, in fact, believed secure, meaning there is no documented method, no matter how practical, to begin with a hash digest and produce a colliding message that requires less work than simply trying every possibility (which for SHA-256 is ideally 2^256 ~= 10^77 possibilities).