WordPress get_post_meta Example: Read Custom Fields Safely

Last reviewed: May 12, 2026

get_post_meta() looks simple, but a lot of WordPress code still reads post metadata loosely and then treats the result as if it were strongly typed. That is where subtle bugs start: empty strings become false assumptions, arrays arrive where a single value was expected, and rendering code trusts meta it never validated.

This guide shows how to retrieve post meta safely, how the $single flag changes return behavior, and why downstream type handling matters just as much as the read itself.

Request one key deliberately and choose the expected shape

<?php
$severity = get_post_meta( $post_id, '_vulnwp_severity', true );

if ( $severity === '' ) {
	$severity = 'low';
}

Passing a specific meta key with $single set to true makes the calling code much easier to reason about. Without that, retrieval logic often becomes more defensive than it needs to be.

Remember that non-existing values do not always come back as null

The code reference is explicit: for a valid post ID and missing key, get_post_meta() returns an empty string when $single is true, and an empty array when it is false. That difference matters for defaulting logic and conditional checks.

Do not confuse retrieval with trust

Reading metadata does not prove the value is valid for the current render or workflow. If a meta field is used in a URL, permission decision, CSS class, or numeric threshold, it still needs the right validation and escaping path for that use case.

Use stable key casing

The WordPress reference notes a subtle edge: metadata queries can interact poorly with mixed key casing because caching behavior is case sensitive even when the database collation is not. In practice, stable lowercase key naming avoids unnecessary confusion.

Common mistakes

• Using the wrong $single mode. The value shape changes with it.
• Assuming missing meta returns null. WordPress uses empty string or empty array instead.
• Reading metadata and trusting it immediately. Output and business rules still need validation.
• Mixing meta key casing over time. That creates avoidable cache-related confusion.

Production checklist

• Read one explicit meta key at a time when possible.
• Use $single = true when the field contract is one value.
• Handle empty-string defaults deliberately.
• Validate and escape the value for its final context.
• Keep meta keys consistently cased across the codebase.

Related reading

Pair this with the meta box guide for the write path and with the register_post_meta article when the same field needs a safer REST contract.

References and further reading

• WordPress Code Reference: get_post_meta()
• WordPress Code Reference: update_post_meta()
• WordPress Code Reference: register_post_meta()