Image Captions


When adding an image block to a page, I often want to provide either some description of the image, or add details which aren’t described by the image itself; what song was playing in the background at the time the image was taken, for example.

Adding captions as a property to the image block would facilitate this functionality in a way in which many users of other tools are already familiar. Captions would also be a useful source of alt-text for the vision impaired.

Describe the solution you’d like

I would like the ability to add (and delete) caption text to image blocks inside Anytype. Captions should be associated with an image, and when populated, be rendered in close proximity to the image within the user interface.

I would like to see captions be able to be added as an inherent property of image blocks, perhaps via the object menu:

Describe alternatives you’ve considered

Currently to achieve a “caption” like experience, I’m simply using text blocks directly after the image in the same column.

Why is this not an appropriate solution?

A caption should be logically associated with an image, and in fact may not make any sense without the content of the image. By using the “caption like experience” I describe above, the text block below is not actually linked to the image, so any movement of that image does not include the movement of the text block “caption”.

Additional context

Below is an example of how my “caption like experience” works, using a text block:

In Notion, this is achievable with an actual caption, which appears as such:


Bumping this, it would be really nice to have.

1 Like


1 Like

From TBD to TBA?

You can say: I was there at a time of uncertainty.


I suggest this to be a specific case of the general “everything is a Block” approach (as I describe [here](Everything is a... Block?)). That way lots of other cool things like that could be achieved using the same principle.

In the link above I suggest a Relation could be implemented as a Property Block instead, which would apply to their parent Block. Any Property Block could also include information regarding how it should be displayed.

So in the OP’s situation, the Caption would be a Property Block, child to the Picture Block, with display set to appear as smaller font under the image.

Interesting, however I wonder if this would not lead to more manipulations or complexity?

@AyneHancer You’re right. There should always be a simple/easy way to do something. Then if you want more complexity, you have the option. (Like they do currently with the Types - a user can just use existing Types without ever bother creating their own, if they so wish).

For example, a user simply wanting to add a caption to an image, should be able to do so easily. For example, click on its handle and choose Add Caption in the menu. They don’t even need to know that in the background this is really adding a Property Block called Caption to that Picture Block.

For the user wanting to create a simple Property Block (Relation), they should still be able to do so quickly by only picking Name and Type (as it is now).

Users wanting to create more complex Property Blocks could do so by perhaps going into its “page”, and expanding a “More options” section at the bottom.


Currently the “page” for a Relation (what I’m calling a Property Block) is quite empty. Most users might never even go in here.

In the caption example, this page could look like this:

  • Title: Caption
  • Type: String
  • Display: immediately below parent
  • Format: small grey font
  • How to add: handle menu

(Note all the extra options above are optional… Also, these options are essentially just Blocks as well. One could even add a Caption property to itself, which means you could add a Caption block to a Caption block. :laughing: )

1 Like

@qualquertipo I like the idea of establishing ( parent <-> child ) <-> style relationship between relations. i for one wanted a way to add a code block to the right or the bottom of a text block to add snippets of the code a text block is explaining. Maybe like custom types, relations, custom block option should solve this, but this sounds more like a great idea for the plugin system which is planned for the future as the development team can then concentrate on stabilizing the API and the software

This is already possible just by indenting blocks, no?

Or did you mean something else?

Exactly! I’m really looking forward to all the extensions/plugins that will be possible when they open up the API.

This is part of the reason I am suggesting to have the core structure be simpler (ie. everything is a block). I feel this would give developers more flexibility (rather than needing to work with objects, blocks, sets and relations). I’m not a developer though (just a casual coder), so this is just my guess.

Yes it is possible now but having the relationship like you’ve said could possibly enable one to couple such things together, like the description block is coupled with the code block which would enable other plugins to style them as a whole or something like that :sweat_smile: the possibilities are endless

@lynxlove Ah yes! Exactly.

What I am suggesting doesn’t really change what is already there (the Blocks, and how they can be nested into each other). The idea is just to leverage that existing elegant fundamental unit to represent all the others.

The UI can have abstractions for all of that (ie. once the block is setup, the user doesn’t have to think “I shall now create a child block styled in such a way that it looks like a caption”; they can just find the “Add caption” option in a menu).