DEV Community: GREG T

What Is a Hash Function? Checksums, Passwords, and Fingerprints

GREG T — Tue, 22 Sep 2026 05:17:57 +0000

Hash functions are one of the quiet workhorses of computing. They verify your downloads, identify your git commits, detect duplicate files, and protect stored passwords - all without most people ever noticing. This article explains what a hash function actually does, the differences between the common algorithms, and the single most important thing to understand about them.

What a hash function does

A hash function takes input of any size - a word, a file, a multi-gigabyte disk image - and produces a fixed-length string called a hash or digest. The same input always produces the same output, but the output looks nothing like the input:

hash("hello")  = 5d41402abc4b2a76b9719d911017c592
hash("hellO")  = 8b1a9953c4611296a827abf8c47804d7

Notice how changing a single letter completely transformed the result. This is called the avalanche effect, and it is a defining property of a good hash function: a tiny change in the input produces a wildly different output.

The key idea: hashing is one-way

This is the part people most often get wrong. Hashing is not encryption. Encryption is reversible - with the key, you can recover the original. Hashing is deliberately one-way: there is no key, and there is no function that turns a hash back into the original input. The digest is a fingerprint, not a locked box.

That one-way property is exactly what makes hashing useful for the jobs below. It is also why you must never think of a hash as a way to "hide" data - identical inputs always produce identical hashes, so common values can be looked up in precomputed tables.

What hashes are used for

Verifying downloads. A software vendor publishes the SHA-256 of a file. You hash your copy and compare - if the values match exactly, your download is intact and untampered.
Detecting duplicates. Two files with the same hash are (practically certainly) identical, so deduplication systems compare hashes instead of comparing every byte.
Storing passwords. Servers store the hash of your password, not the password itself. When you log in, they hash what you typed and compare. A breach leaks hashes, not plain passwords - provided the right algorithm was used.
Data integrity. Git identifies every commit by a hash of its contents, which is how it detects corruption and links history together.

MD5, SHA-1, SHA-256: which to use

Not all hash functions are equal, and some are now broken for security purposes:

MD5 - fast but cryptographically broken. Attackers can deliberately create two different inputs with the same MD5 (a "collision"). Never use it for security. It is still fine for non-security tasks like detecting accidental file corruption.
SHA-1 - also broken for security since 2017. Being phased out everywhere.
SHA-256 - part of the SHA-2 family and the current general-purpose standard. Fast, widely supported, and with no known practical collisions. This is the right default.
SHA-512 - a larger sibling of SHA-256, useful when you want an even bigger digest.

A crucial note on password hashing

For passwords specifically, even SHA-256 is not enough on its own - it is too fast, which lets attackers try billions of guesses per second. Real password storage uses deliberately slow algorithms designed for the job, such as bcrypt, scrypt, or Argon2, combined with a unique random "salt" per password. If you are building authentication, use one of those, never a plain hash.

Want to see hashing in action? The generator below computes MD5, SHA-1, SHA-256, and SHA-512 of any text instantly and locally - handy for verifying a checksum or comparing whether two pieces of text are identical.

Originally published at devtools.fit, where I keep a set of free browser-based dev tools.

Understanding Cron Jobs: How to Read and Write Schedules

GREG T — Sat, 19 Sep 2026 05:12:25 +0000

Behind almost every recurring automated task - nightly backups, hourly data syncs, the weekly report that lands in your inbox every Monday - there is usually a cron job. Cron is the time-based scheduler that has run the Unix world since the 1970s, and its compact syntax now appears far beyond Unix: in GitHub Actions, Kubernetes, cloud functions, and CI pipelines. Learning to read it is a genuinely useful skill.

The five fields

A standard cron expression is five fields separated by spaces. Each field controls one unit of time:

*  *  *  *  *
|  |  |  |  |
|  |  |  |  +-- day of week  (0-7, 0 and 7 = Sunday)
|  |  |  +----- month        (1-12)
|  |  +-------- day of month (1-31)
|  +----------- hour         (0-23)
+-------------- minute       (0-59)

An asterisk (*) means "every value." So * * * * * means "every minute of every hour of every day" - the most frequent schedule cron allows.

The special characters

Each field accepts more than just a number or an asterisk:

Comma for lists: 0,15,30,45 in the minute field means at 0, 15, 30, and 45 minutes past the hour.
Hyphen for ranges: 1-5 in the day-of-week field means Monday through Friday.
Slash for steps: */15 in the minute field means every 15 minutes; */2 in the hour field means every other hour.

Reading real examples

0 9 * * 1-5     -> at 09:00, Monday to Friday
*/15 * * * *    -> every 15 minutes
0 0 1 * *       -> at midnight on the 1st of every month
30 3 * * 0      -> at 03:30 every Sunday
0 */6 * * *     -> every 6 hours (00:00, 06:00, 12:00, 18:00)

The pattern to internalize: read the fields left to right as minute, hour, day-of-month, month, day-of-week, and translate each special character. With a little practice, 0 9 * * 1-5 reads instantly as "9 AM on weekdays."

The timezone gotcha that causes outages

Here is the mistake that has broken countless production systems: classic cron has no timezone field. A job runs in whatever timezone the host machine is set to. Most servers run in UTC, so a job you scheduled for "9 AM" fires at 9 AM UTC - which might be 10 or 11 AM where you live, and shifts by an hour when daylight saving time changes.

If a scheduled report arrives an hour "late" twice a year, this is almost always why. When precise local timing matters, either set the schedule in UTC deliberately, or use a scheduler that supports an explicit timezone.

The day-of-month and day-of-week trap

One more surprise: when you set both the day-of-month and the day-of-week fields, standard cron combines them with OR, not AND. So 0 0 13 * 5 does not mean "midnight on Friday the 13th" - it means "midnight on the 13th of every month, and midnight every Friday." If you only want one of the two conditions, leave the other as *.

Test before you deploy

Because a single wrong character can mean a backup that silently never runs, always verify a cron expression before trusting it. The parser below translates any expression into plain English and shows the next several run times, so you can confirm a schedule does exactly what you intended.

Originally published at devtools.fit, where I keep a set of free browser-based dev tools.

Hexadecimal Explained: Why Programmers Count in Base 16

GREG T — Tue, 15 Sep 2026 13:45:18 +0000

Color codes like #FF6B35, memory addresses like 0x7FFE, hashes, MAC addresses, error codes - all of them are written in hexadecimal. For newcomers, base 16 looks intimidating, but it is one of the most useful and approachable ideas in computing once it clicks. Here is the whole concept, from the ground up.

Counting beyond ten

We count in base 10 because we have ten fingers: the digits 0-9, and when we run out we add a new place (9 -> 10). Hexadecimal is base 16: it has sixteen digits. Since we only have ten number symbols, hex borrows the first six letters of the alphabet for the rest:

Decimal:  0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Hex:      0 1 2 3 4 5 6 7 8 9  A  B  C  D  E  F

So A is ten, F is fifteen, and the next number after F is 10 in hex - which equals sixteen in decimal. To avoid confusion, hex values are usually prefixed with 0x (as in 0x10) or # for colors.

Converting hex to decimal

Each position in a hex number is a power of 16, read right to left: the rightmost digit is the 1s place, then 16s, then 256s, and so on. Take 0x2F:

2F = (2 x 16) + (15 x 1)
   = 32 + 15
   = 47

And 0xFF, the famous maximum of a single byte:

FF = (15 x 16) + (15 x 1) = 240 + 15 = 255

Why hex and binary are best friends

Here is the reason hex dominates programming: one hex digit represents exactly four binary digits (bits). Four bits can hold sixteen values - precisely the range of one hex digit. That makes the conversion mechanical:

Binary:  1111 1111
Hex:        F    F   =  0xFF
Binary:  0010 1010
Hex:        2    A   =  0x2A

A byte is eight bits, so it is always exactly two hex digits. This is why memory dumps, color channels, and hashes are shown in hex: it is a compact, lossless shorthand for binary that humans can actually read. Writing 0xFF is far easier than 11111111, and you can convert between them in your head once you memorize the sixteen patterns.

Where you will meet hexadecimal

Colors: #FF6B35 is three bytes - red FF (255), green 6B (107), blue 35 (53).
Memory addresses: debuggers and low-level code show locations like 0x7FFE3210.
Hashes and checksums: an MD5 or SHA value is just a long hex string.
Character codes: Unicode code points are written as U+1F600 in hex.
Permissions and flags: bit masks are often expressed in hex for compactness.

Octal, the third base

You will occasionally see base 8 (octal), most famously in Unix file permissions: chmod 755. Each octal digit encodes three permission bits for owner, group, and others. Octal groups bits in threes the way hex groups them in fours.

The fastest way to build intuition is to convert numbers back and forth and watch the patterns. The converter below shows binary, octal, decimal, and hex side by side - type in any field and the others update instantly.

Originally published at devtools.fit, where I keep a set of free browser-based dev tools.

camelCase vs snake_case vs kebab-case: Naming Conventions Explained

GREG T — Wed, 09 Sep 2026 05:48:28 +0000

Every programmer eventually wonders: should this variable be userName, user_name, or user-name? These are not random style choices - each convention has a name, a history, and a set of languages and contexts where it is the norm. Getting them right makes your code look native to the ecosystem you are working in. Here is the complete map.

The four main conventions

camelCase - first word lowercase, each following word capitalized: userName, maxRetryCount. Named because the capital letters look like a camel's humps.
PascalCase (also called UpperCamelCase) - like camelCase but the first letter is also capitalized: UserName, HttpClient.
snake_case - all lowercase, words joined by underscores: user_name, max_retry_count.
kebab-case (also called dash-case) - all lowercase, words joined by hyphens: user-name, main-content. Named because the words look skewered like a kebab.

There is also SCREAMING_SNAKE_CASE - snake_case in all capitals (MAX_SIZE, API_KEY) - reserved almost everywhere for constants.

Which convention goes where

The conventions are not interchangeable; communities have settled on strong norms:

JavaScript / TypeScript: camelCase for variables and functions, PascalCase for classes and React components.
Python: snake_case for variables and functions, PascalCase for classes, SCREAMING_SNAKE_CASE for constants (this is the PEP 8 standard).
Ruby: snake_case for methods and variables, PascalCase for classes.
Go: PascalCase for exported names, camelCase for unexported ones - capitalization is actually meaningful to the compiler.
CSS: kebab-case for class names and custom properties (--main-color).
URLs and file names: kebab-case, because hyphens are read as word separators by search engines and are easy to read in links.
Database columns: usually snake_case.

Why hyphens cannot be used in code

You may wonder why kebab-case is fine for CSS and URLs but never for variables. The reason is that most programming languages interpret the hyphen as the minus operator - user-name would be parsed as "user minus name." That is why code uses camelCase or snake_case (both made only of letters, digits, and underscores) while markup and URLs, which have no arithmetic, can use hyphens freely.

Converting between conventions

Renaming identifiers from one convention to another by hand is tedious and error-prone, especially across a large file or when porting code between languages. The mechanical rules are:

To camelCase / PascalCase: remove separators, capitalize the letter after each removed separator.
To snake_case / kebab-case: insert a separator before each capital letter, then lowercase everything.

Edge cases - acronyms like HTTPServer, leading capitals, numbers - are where manual conversion tends to slip. A converter handles them consistently.

Consistency beats correctness

If there is one rule above all others, it is this: match the surrounding code. A "wrong" convention used consistently is far more readable than the "right" one applied haphazardly. When you join a project, adopt its conventions even if they differ from your personal preference. Linters and formatters can enforce this automatically.

Need to switch some text between cases right now? Paste it into the converter below and get UPPERCASE, lowercase, Title Case, camelCase, PascalCase, snake_case, and kebab-case in one click.

Originally published at devtools.fit, where I keep a set of free browser-based dev tools.

What Is a JWT? JSON Web Tokens Explained Simply

GREG T — Sat, 05 Sep 2026 05:28:41 +0000

JSON Web Tokens - JWTs, usually pronounced "jots" - are the most common way modern web applications prove who you are after you log in. If you have ever inspected the network traffic of a web app and seen a long string in three dot-separated parts, that was almost certainly a JWT. Here is what they are and how they work, without the jargon.

The problem JWTs solve

HTTP is stateless: each request arrives with no memory of the previous one. So after you log in, how does the server know it is still you on the next request? The traditional answer was server-side sessions: the server stores your session in memory or a database and gives you a cookie with a session ID. That works, but it means the server has to look up and store state for every logged-in user.

JWTs flip this around. Instead of the server remembering you, it gives you a signed token that contains your identity. On each request you send the token back, and the server simply verifies the signature. No lookup, no shared session store - which is why JWTs scale so well across multiple servers.

The three parts of a JWT

A JWT is three Base64Url-encoded pieces joined by dots: header.payload.signature.

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiQWxpY2UifQ.SflKxw...
        header                    payload                signature

Header - says what type of token it is and which signing algorithm was used (for example HS256).
Payload - the "claims": the actual data, such as the user ID (sub), name, roles, and an expiry time (exp).
Signature - a cryptographic seal over the header and payload, created with a secret key only the server knows.

The most important thing to understand

A JWT is signed, not encrypted. The payload is merely Base64-encoded, which is trivially reversible - anyone who has the token can read its contents. Paste any JWT into a decoder and the claims appear in plain text, no key required.

So what does the signature protect? Tampering. If an attacker changes the payload - say, flipping "role": "user" to "role": "admin" - the signature no longer matches, and the server rejects the token. The signature proves the token was issued by your server and has not been altered; it does not hide the contents.

What you should and should not put in a JWT

Because the payload is readable by anyone holding the token, treat it as public:

Good to include: a user ID, roles or permissions, the token's expiry. Just enough to identify the session.
Never include: passwords, credit card numbers, personal data, or any secret. If the token leaks into a log, a URL, or browser history, everything in it is exposed.

Expiry and security tips

Always set an expiry (exp). A token that never expires is a permanent key if stolen. Short lifetimes (minutes to hours) limit the damage.
Use refresh tokens for long sessions: a short-lived access token plus a longer-lived refresh token that can be revoked.
Store them carefully in the browser. localStorage is vulnerable to cross-site scripting; HttpOnly cookies are safer against that particular attack.
Most "login bugs" are expiry bugs. When debugging a 401, decode the token and check the exp claim first - it is usually expired or the server clock is off.

To see what is inside a token, paste it into the decoder below. It splits the JWT and shows the header and payload - including human-readable dates for the issued-at and expiry claims - entirely in your browser, so the token is never sent anywhere.

Originally published at devtools.fit, where I keep a set of free browser-based dev tools.