Raza Photos and Raza Songs build a small JPEG copy of each photo or cover the first time it appears on screen, and keep it so the grid is fast the next time. The limit in Settings decides how many of those copies are kept ready. Your originals are only ever read, and the cache can be cleared at any time.
A grid can show thousands of items at once. Decoding thousands of full-size originals every time you scroll would be slow and would keep your Mac and your network busy, so each item gets a small stand-in that is cheap to load.
Making that stand-in only reads the original. Nothing is written to your photo or song files, and the thumbnail is not used when you open the full photo.
How a thumbnail is made
It happens once per item, the first time you scroll it into view.
The app checks memory first, then the cache folder on disk. If it finds a thumbnail, it uses it and stops there.
On a miss, the Mac opens the original and produces a version no larger than 320 pixels on its longest edge. It builds that from the image itself rather than from the tiny preview some cameras embed, and it applies the photo's orientation so portraits come out upright.
For a video, the thumbnail is the first frame. For a song, it is the cover art embedded in the file, or the cover you picked and haven't saved yet.
The result is saved to the cache folder as a JPEG at 60% quality, named after the item's internal ID. The write is atomic, so an interrupted write never leaves a half-finished file.
The next appearance reads that small file instead of the original. The most recent 200 thumbnails are also kept in memory, so scrolling back and forth over a screenful costs almost nothing.
What one thumbnail costs
What the limit changes
Not whether your photos show up. Every photo and cover appears in the grid whatever the limit is, and whatever the size of your library. A thumbnail that isn't in the cache is simply built the moment it is needed, and the oldest ones are removed to make room. The limit only decides how many are kept ready, so scrolling back stays instant.
There is nothing to calculate. For a sense of scale, at about 20 KB each, these are the number of thumbnails each choice keeps ready at once:
The default suits nearly everyone. A bigger library doesn't need a bigger limit, and you don't need to count anything. Raise it only if you'd like more of the grid to stay instant, or lower it if you'd rather keep disk space.
What happens when the cache is full
Each time a new thumbnail is saved, the app checks the total. If it is over the limit, it removes the oldest thumbnails, oldest first by the time they were created, until the total is back under the limit. Lowering the limit in Settings triggers the same cleanup straight away.
Removing a thumbnail costs nothing but a little time. The next time that item appears, it is built again from the original.
A thumbnail that was removed is rebuilt when you scroll back to it, so that first view takes a moment longer. Rebuilding needs the original: a photo folder on a disconnected drive has to be back first, and on an iPhone the Mac has to be on and reachable. A larger limit makes this happen less often.
The same applies to Clear thumbnail cache in Settings. It removes every thumbnail, and they return as you browse. Nothing else is touched. macOS can also empty app cache folders on its own when disk space runs low, with the same result.
On iPhone and iPad
Your iPhone never has your originals, so it can't build thumbnails itself. When a grid cell needs one, the iPhone asks the Mac, the Mac builds or loads the 320 pixel JPEG and sends it over your home network, and the iPhone keeps its own copy in its own cache folder. The next view comes from the phone, with no round trip.
The phone has its own cache limit, with the same four choices, set in the iOS Settings app under Raza Photos or Raza Songs, and its own Clear option. Clearing the phone's cache doesn't touch the Mac's, and the other way around.
Nothing is added to your library folders
The cache lives inside each app's own storage on your Mac, not next to your photos or songs. Some apps can add files of their own to the folders they index, such as artwork, metadata files or thumbnail folders, and those then travel with every copy and backup of your library. Raza Photos and Raza Songs don't create any folders in yours.
Two things are written into your library folders, and both are things you asked for: metadata you choose to save into a file, and photos you send from your iPhone into the folder you picked. Thumbnails, the library database, and anything pending are kept elsewhere. If you want nothing but your own files in your library, that is how it stays.
What the thumbnail cache is not
- The full-size photo. Opening a photo reads the original from your Mac each time, and the result is not stored on disk. That is what keeps the cache small.
- The large artwork in Now Playing. Raza Songs decodes the cover at up to 1,200 pixels each time you play a track and doesn't keep it.
- The Photo of the Day widget. It keeps its own 640 pixel copy of the current photo, with its own Clear button in Settings.
- Your edits. Pending changes to titles, dates, places or covers live in the library database or a separate folder, never in the thumbnail cache, so clearing it loses nothing. How saving works →
Photo and cover thumbnails are created with Image I/O's CGImageSourceCreateThumbnailAtIndex, with kCGImageSourceCreateThumbnailFromImageAlways so the
result comes from the image data and not an embedded preview, kCGImageSourceThumbnailMaxPixelSize set to 320, and
kCGImageSourceCreateThumbnailWithTransform so EXIF orientation is applied. The size is a bounding box, so portrait and landscape both fit it. Video thumbnails come
from AVAssetImageGenerator at time zero with the track transform applied. Cover art is read from the ID3 attached picture or the MP4 covr atom.
Each thumbnail is encoded as JPEG at quality 0.6 and written atomically as <UUID>.jpg in a Thumbnails folder inside the app's
Caches directory, the one place the system is allowed to reclaim under disk pressure. Eviction sorts the folder by modification date and deletes from the oldest
until the total is under the limit. A reader doesn't update that date, so the order is "oldest created", not "least recently viewed". The memory layer is an NSCache
with a count limit of 200.
The Settings screen shows the folder, its current size and a Clear button. You can open the folder in Finder from there and look at the files yourself.