Run the command "du -ch /Applications" on terminal, note down its size.
Now look at the size of /Applications folder from "Get Info" option.
There is a major difference size shown. Same is true for any other folder.
What is the reason for this difference, which one of it is the exact size?

Questions on Stack Overflow are expected to relate to programming within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.
If this question can be reworded to fit the rules in the help center, please edit the question.

It does default to 512 bytes or $BLOCKSIZE (documented in the man page) - this convention goes back decades, I guess probably because old Unix filesystems used 512-byte blocks? If you use -h the block size is ignored though.
–
Nicholas RileyApr 26 '11 at 18:15

I am not sure the reason is this because the difference is much more than what may come because of base 10 and base 2. The outputs for /Applications folder on my machine are: from "Get Info" 925.3 MB, from "du -ck /Applications" 477596, from "du -c /Applications" 955192 and from "du -ch /Applications" 466M
–
rohitsApr 27 '11 at 5:22

Perhaps you've got lots of data in non-data forks? As far as I know du isn't fork-aware but the Finder is. I'd suggest you dig into individual subdirectories of /Applicstions to see if this is the case, or if it may be related to filesystem compression as the other answer mentions. Probably best to start with a small Apple app.
–
Nicholas RileyApr 27 '11 at 5:30

Do you use the system provided du, or some du you installed from the source?

The vast difference in the size shown can be because of the file system compression, not seen by some of the BSD tools. It basically works by putting a compressed version of a file in the resource fork of the file, keeping the data fork empty. When the file is read, the content is automatically decomporessed. But some of the BSD API reports the bare size of the data fork, thus missing the size of the real data in the resource fork.